The title I think says it all. Originally I though it might be a 64-bit program running on a 32-bit O/S - not the case as far as I can see.
yoctoadm#kickseed:/ntg6src/source/packages/sdk_armv8/sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial
// uname -a output
yoctoadm#kickseed:/ntg6src/source/packages/sdk_armv8/sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux$ uname -a
Linux kickseed 4.4.0-165-generic #193-Ubuntu SMP Tue Sep 17 17:42:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
// file aarch64-gnu-linux-g++ output
yoctoadm#kickseed:/ntg6src/source/packages/sdk_armv8/sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux$ file aarch64-gnu-linux-g++
aarch64-gnu-linux-g++: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /ntg6sdk, for GNU/Linux 2.6.32, BuildID[sha1]=0bc9f03b2a2bee373f6ec3c85527230243579763, stripped
// no such file or directory error
yoctoadm#kickseed:/ntg6src/source/packages/sdk_armv8/sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux$ ls
aarch64-gnu-linux-addr2line aarch64-gnu-linux-dwp aarch64-gnu-linux-gcc-nm aarch64-gnu-linux-gdb aarch64-gnu-linux-nm aarch64-gnu-linux-size
aarch64-gnu-linux-ar aarch64-gnu-linux-elfedit aarch64-gnu-linux-gcc-ranlib aarch64-gnu-linux-gprof aarch64-gnu-linux-objcopy aarch64-gnu-linux-strings
aarch64-gnu-linux-as aarch64-gnu-linux-g++ aarch64-gnu-linux-gcov aarch64-gnu-linux-ld aarch64-gnu-linux-objdump aarch64-gnu-linux-strip
aarch64-gnu-linux-c++filt aarch64-gnu-linux-gcc aarch64-gnu-linux-gcov-dump aarch64-gnu-linux-ld.bfd aarch64-gnu-linux-ranlib
aarch64-gnu-linux-cpp aarch64-gnu-linux-gcc-ar aarch64-gnu-linux-gcov-tool aarch64-gnu-linux-ld.gold aarch64-gnu-linux-readelf
yoctoadm#kickseed:/ntg6src/source/packages/sdk_armv8/sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux$ ./aarch64-gnu-linux-g++
bash: ./aarch64-gnu-linux-g++: No such file or directory
The environment variables weren't setup correctly. It was necessary to "source" the environment file, which exports the correct environment variables.
Related
I have a problem when I try to start my server Garry's Mod. Here is the error I get
Failed to open dedicated_srv.so (/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by bin/dedicated_srv.so))
Add "-debug" to the ./srcds_run command line to generate a debug.log to help with solving this problem
Sun May 13 01:17:52 CEST 2018: Server restart in 10 seconds
strings /usr/lib/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBC_2.0
GLIBC_2.3
GLIBC_2.4
GLIBC_2.1
GLIBC_2.1.3
GLIBC_2.3.2
GLIBC_2.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH.
There you have a way to have glibcxx_ 3.4.15 on CentOS 6.9, Because I really need CentOS 6 to run other applications ?.
Thanks for your help.
Just try to install file libstdc++-4.8.5-28.el7.i686.rpm
yum install http://centos.biz.net.id/7/os/x86_64/Packages/libstdc++-4.8.5-28.el7.i686.rpm
.
[root#linux ~]# cat /etc/redhat-release
CentOS release 6.7 (Final)
[root#linux ~]# strings /usr/lib/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBC_2.3
GLIBC_2.0
GLIBC_2.4
GLIBC_2.1
GLIBC_2.1.3
GLIBC_2.3.2
GLIBC_2.2
GLIBCXX_DEBUG_MESSAGE_LENGTH
[root#linux ~]#
I am trying to build all the recipes I made for my target architecture for my host systems architecture (x86_64), with the intention of being able to install these RPM's in x86_64 environments.
To do this I simply set MACHINE=genericx86-64 and build; however, the resulting RPM's seem to have their architecture set to core2_64. I guess it is related to the TUNE_FEATURES="m64 core2" reported when running bitbake (see below).
How can I make sure that these RPM's end up as x86_64 so that my host (RHEL7) accepts them?
Build Configuration:
BB_VERSION = "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal-4.8"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "genericx86-64"
DISTRO = "generic-panel"
DISTRO_VERSION = "0.7"
TUNE_FEATURES = "m64 core2"
TARGET_FPU = ""
Example
# rpm -i xxx.core2_64.rpm
package xxx.core2_64 is intended for a different architecture
$ uname -a
Linux localhost 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
The solution was to modify the DEFAULTTUNE variable, so i just added DEFAULTTUNE_genericx86-64 = "x86-64" to my local.conf.
I tried to change the ipython qtconsole font size with reference to this answer in stackoverflow; however, the font size refused to change no matter how I change the ~/.ipython/profile_default/ipython_config.py.
➜ ~ ipython profile locate
/home/nick/.ipython/profile_default
➜ ~ head .ipython/profile_default/ipython_config.py
# Configuration file for ipython.
c = get_config()
c.IPythonWidget.font_size = 16
c.IPythonWidget.font_family = 'Source Code Pro'
➜ ~ uname -a
Linux nick-thinkpad 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86
_64 GNU/Linux
➜ ~ ipython --version
4.0.0
To my suprise, ipython qtconsole --ConsoleWidget.font_size=16 works. What's wrong with my configuration?
From version 4.0 on ipython qtconsole is deprecated (because of the big split). Instead, use jupyter qtconsole. You can set the fontsize by adding c.ConsoleWidget.font_size = 12 to ~/.jupyter/jupyter_qtconsole_config.py (this also sets the font size for ipython qtconsole).
Be aware of a bug in jupyter that does not allow you to automatically create a default config file. For now, you just have to create that file manually.
I am working on matlab R2013a on Ubuntu. I am referring this code:
sift_bin = fullfile('lib/sift/bin/siftfeat');
[pf,nf,ef] = fileparts(filename);
desc_file = [fullfile(pf,nf) '.txt'];
im1=imread(filename);
if (size(im1,1)<=1000 && size(im1,2)<=1000)
status1 = system([sift_bin ' -x -o ' desc_file ' ' filename]);
else
status1 = system([sift_bin ' -d -x -o ' desc_file ' ' filename]);
end
But it gives an error:
lib/sift/bin/siftfeat cannot execute binary file
Is there anything wrong with system call?
lib/sift/bin/siftfeat is a path of sift library.
Use file utility to make sure that file is an executable and see its architecture
system('file /bin/ls')
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=0xf31e99218b4d7034cf8257055686bca22f5a3c01, stripped
ans = 0
Then uname -a shows architecture of your system
system('uname -a')
Linux optiPlex7010 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
ans = 0
As one can see I have 64-bit Linux and executable is also 64-bit. However, when it comes to 32-bit systems and executable support is backward compatible. That means 64-bit system may execute both 32-bit and 64-bit executables, but 32-bit system can execute only 32-bit executables.
From your comments I see that you are trying to launch 64-bit executable in 32-bit system, which is not capable of doing that. You should find 32-bit version of siftfeat or change your OS to 64-bit, if that is possible.
I am puzzled by the following sequence of commands.
sh-4.2$ pwd
/home/willard
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ file f
f: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xea0e08ff2b5a062698d45b78177acdd6bf140d1f, stripped
sh-4.2$ ./f
sh: ./f: No such file or directory
sh-4.2$ strace ./f
execve("./f", ["./f"], [/* 32 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ uname -a
Linux xdat10 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux
How is this possible?
I found someone having the same problem (with relative explanation)
Running 32bit binary on a 64bit system
Quoting the most important sentences:
This situation often arises when you try to run a binary for the right
system (or family of systems) and superarchitecture but the wrong
subarchitecture. Here you have ELF binaries on a system that expects
ELF binaries, so the kernel loads them just fine. They are i386
binaries running on an x86_64 processor, so the instructions make
sense and get the program to the point where it can look for its
loader. But the program is a 32-bit program (as the file output
indicates), looking for the 32-bit loader /lib/ld-linux.so.2, and
you've presumably only installed the 64-bit loader
/lib64/ld-linux-x86-64.so.2 in the chroot.
You need to install the 32-bit runtime system in the chroot: the
loader, and all the libraries the programs need. On Debian amd64, the
32-bit loader is in the libc6-i386 package. You can install a bigger
set of 32-bit libraries by installing ia32-libs.
I bet there's a better way to verify this but i'd try to exec
ldd ./f
and search in the output which loader is needed to exec'it
man 2 execve:
ENOENT The file filename or a script or ELF interpreter does not
exist, or a shared library needed for file or interpreter can‐
not be found.
You could run ldd against this binary to look for libraries that could not be mapped and install them from multilib.