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.
Related
Running RHEL 7.7 on the head node of a compute cluster. When I open VS Code 1.57.1 it hangs on the intro screen. Running with $ code --verbose, it shows the error: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.20 not found. I have to kill -9 the hanging code process. Google tells me that the new version of VS Code uses Electron that requires the updated GLIBCXX version.
The installed version in /usr/lib64/libstdc++ is definitely out of date, and I can't update it. But I do have a newer version of GCC that is loaded by the $ module load gcc8/8.4.0 command that loads GCC from /cm/shared/apps/gcc8/8.4.0/. The library /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 has the requested version of GLIBCXX.
I have tried loading gcc8 before running code, but that doesn't change the error.
Is there a way to make VS Code use the alternative location for libstdc++.so.6? Is there an alternative to updating the system-wide libstdc++.so.6 library?
This is the full error message from --verbose:
Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1846)
This shows the out-of-date default version of libstdc++:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.18
GLIBCXX_3.4.19 <----Nope, this version is too old!
GLIBCXX_DEBUG_MESSAGE_LENGTH
This shows the other libstdc++ library has the required version:
$ strings /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.19
GLIBCXX_3.4.20 <--- Here it is!
GLIBCXX_3.4.21
...
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH
Per scroveez's suggestion, the /usr/lib64/libstdc++.so.6 was indeed a symlink to the older version. To fix it I copied the 'new' version 25 library into /usr/lib64/ and changed the symlink to point to the newer version.
$ ll /usr/lib/libstdc++.so.*
lrwxrwxrwx 1 root root 18 Apr 30 2019 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 739520 Nov 13 2014 /usr/lib/libstdc++.so.5.0.7
lrwxrwxrwx 1 root root 19 Jul 6 08:56 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.25
-rwxr-xr-x 1 root root 934644 Mar 25 2020 /usr/lib/libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 1570176 Jul 6 08:55 /usr/lib/libstdc++.so.6.0.25
$
I am attempting to run perl CGI script on RHEL 7, i've used yum installer and it's successfully installed 5.26, i can run perl programs from terminal without problem, but when i run a simple CGI script it writes error to httpd/error.log. I've posted the exact error below.
enabled software collection
$scl enable rh-perl526 bash
perl -v
This is perl 5, version 26, subversion 3 (v5.26.3) built for x86_64-linux-thread-multi
(with 27 registered patches, see perl -V for more detail)
$which perl
/opt/rh/rh-perl526/root/usr/bin/perl
$perl -e 'print "Hello Perl\n"'
Hello Perl
When i run a simple CGI script from browser or curl -XGET, i got 500 internal server for
http://serverip/cgi-bin/test-cgi.pl
apache error
[Wed Mar 24 21:24:38.308033 2021] [cgi:error] [pid 9437] [client x.x.x.x:35220] AH01215: /opt/rh/rh-perl526/root/usr/bin/perl: error while loading shared libraries: libperl.so.rh-perl526-5.26: cannot open shared object file: No such file or directory
[Wed Mar 24 21:24:38.308245 2021] [cgi:error] [pid 9437] [client x.x.x.x:35220] End of script output before headers: test.cgi.pl
I've added libperl.so path to LD_LIBRARY_PATH variable in .bashrc and i've rh-perl526-perl-libs.x86_64 package installed.
While installing rh-perl526, i noticed it also installed default perl on system as well due to YUM dependency
any idea how to fix this issue ?
LD_LIBRARY_PATH needs to set in apache http.conf file
i have added below line in httpd.conf and it worked
SetEnv LD_LIBRARY_PATH /path/to/libperl
I also removed perl 5.16 from system using yum.
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.
Investigating an issue with multiple Perl installations on our (HP UX IA64 system), I came across an executable called perl-dynamic. What is this and what exactly does it do?
More importantly, how do I know which perl executable it actually points to (we have multiple versions mixing version numbers and architectures installed).
bash-4.4$ ll /usr/bin/perl
lrwxr-xr-x 1 root sys 18 Jan 8 16:34 /usr/bin/perl -> /opt/perl/bin/perl
bash-4.4$ ll /opt/perl/bin/perl
lrwxrwxrwx 1 bin bin 14 Jan 8 16:45 /opt/perl/bin/perl -> ./perl-dynamic
Is this a magical perl binary which decides which version and architecture to use?
$ perl -V
Will show you the details.
Both perl-static and perl-dynamic are built with the same configuration (at least for what I can see on my HP-UX 11.31) and both are built with -Dusedl
perl-static is linked with libperl.a (or linked with all .o files), whereas perl-dynamic is linked using libperl.so. You can check the differences with ldd perl-static and ldd perl-dynamic.
There is no functional difference
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.