Short question:
How does llvm-ld locate libstdc++?
Details:
I am getting the following error message:
llvm-ld: error: Cannot find library 'stdc++'
while running llvm-ld. I am trying to understand how llvm-ld searches for libstdc++.
I am setting up a new system and following compilation steps that work on a different system. Eventually I noticed a difference with the LD_LIBRARY_PATH that was set in my .bashrc on the old system that included a large number of directories including for Cadence and other miscellaneous software. I don't want to use the LD_LIBRARY_PATH, I want to be able to link against libstdc++ by supplying the appropriate command line parameters to llvm-ld.
The command I am running is:
llvm-ld -disable-internalize -native -o foo foo.bc4 -L/usr/lib/x86_64-linux-gnu -lpthread -lrt -lstdc++ -lm -v
which results in the following output:
Linking bitcode file 'foo.bc4'
Linked in file 'foo.bc4'
Linking archive file '/usr/lib/x86_64-linux-gnu/libpthread.a'
Linking archive file '/usr/lib/x86_64-linux-gnu/librt.a'
llvm-ld: error: Cannot find library 'stdc++'
However running ls -l /usr/lib/x86_64-linux-gnu/libstdc++* results in:
lrwxrwxrwx 1 root root 19 Apr 15 16:34 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.16
-rw-r--r-- 1 root root 962656 Apr 15 16:36 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
So I don't understand why llvm-ld is not finding this file? Especially since when I compile with with the LD_LIBRARY_PATH set and then run ldd on the resulting executable I get the following output:
linux-vdso.so.1 => (0x00007ffff7ffe000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffff7dc1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffff7ac0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffff77c6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffff75b0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff71f0000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
Which seems to indicate that the version of libstdc++ that I want is /usr/lib/x86_64-linux-gnu/libstdc++.so.6 but I can't figure out why llvm-ld is not locating it with the search path -L/usr/lib/x86_64-linux-gnu.
For reference: uname -a results in: Linux FOO 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
And llvm-ld --version:
LLVM (http://llvm.org/):
LLVM version 3.1svn
Optimized build.
Built Sep 14 2012 (13:22:38).
Default target: x86_64-unknown-linux-gnu
Host CPU: core2
It looks like llvm-ld isn't looking for .so.#. According to the man page:
When looking for a library specified with the -l option, llvm-ld first attempts to load a file with that name from the current directory. If that fails, it looks for liblibrary.bc, liblibrary.a, or liblibrary.shared library extension, in that order, in each directory added to the library search path with the -L option. These directories are searched in the order they are specified. If the library cannot
be located, then llvm-ld looks in the directory specified by the LLVM_LIB_SEARCH_PATH environment variable. If it does not find a library there, it fails.
You can make this work by creating a symlink /usr/lib/x86_64-linux-gnu/libstdc++.so -> libstdc++.so.6.
I usually link with clang directly, since it understands searching for C++ library things better.
Related
I have a container built from base image alpine:3.11
Now I have a binary my_bin that I copied into the running container. From within the running container I moved to /usr/local/bin and I confirmed that the binary is there with the right permissions. Eg
/ # ls -l /usr/local/bin/my_bin
-rwxr-xr-x 1 root root 55662376 Jun 12 18:52 /usr/local/bin/my_bin
But when I attempt to execute/run this binary I get the following:
/ # my_bin init
/bin/sh: my_bin: not found
This is also the case if I switch into /usr/local/bin/ and run via ./my_bin
also if I try using the full path
/# /usr/local/bin/my_bin init
/bin/sh: /usr/local/bin/my_bin: not found
Why am I seeing this behavior? and how do I get to be able to execute the binary?
EDIT 1
I installed file and I can also confirm that the binary is copied and is an executable
file /usr/local/bin/my_bin
/usr/local/bin/my_bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b36f0aad307c3229850d8db8c52e00033eae900c, for GNU/Linux 3.2.0, not stripped
Maybe this gives some extra clues?
Edit 2
As suggested by #BMitch in the answer I also ran ldd and here is the output
# ldd /usr/local/bin/my_bin
/lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
** Edit 3 **
Based on the output of ldd and more googling, I find that running apk add libc6-compat installed the missing libraries and I could then run the binary.
For a binary, this most likely indicates a missing dynamic library. You can run ldd /usr/local/bin/my_bin to see all the libraries that binary uses. With alpine, the most common library to be missing from an externally compiled program is libc. Alpine is built with musl instead of libc, and therefore you'll want to compile programs specifically for Alpine.
For others that may encounter this error in docker containers, I cover various issues in my faq presentation and other questions on the site.
/ # my_bin init
/bin/sh: my_bin: not found
When you execute above line it says file which you are trying to execute can't be found, my_bin is the file in your case.
Check if file is copied properly and with the same name or you might be trying to execute file from different location.
e.g. Try /usr/local/bin/my_bin init if you are not doing cd /usr/local/bin after ls -l /usr/local/bin/my_bin command.
Edit 1
I forgot to mention that I want to use the theano library.
After I reached out to the admin, the cudnn modules were provided by them. However, I am still getting the same error.
$ module load devel/cudnn/10.2
$ python -c "import theano"
Can not use cuDNN on context None: cannot compile with cuDNN. We got this error:
/pfs/work7/workspace/scratch/ul_dco32-conda-0/conda/envs/my_env/bin/../lib/
gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../
x86_64-conda_cos6-linux-gnu/bin/ld: cannot find -lcudnn
collect2: error: ld returned 1 exit status
Mapped name None to device cuda: Tesla V100-SXM2-32GB (0000:3A:00.0)
$ vi $HOME/.theanorc
[global]
floatX = float32
device = cuda
[cuda]
root=$CUDA_HOME/bin
[dnn]
include_path=$CUDA_HOME/include
library_path=$CUDA_HOME/lib64
[lib]
cnmem=1
So, most probably, I have a link problem, however, I can't find it where.
Problem
I am struggling with ld: cannot find -lcudnn.
Description
I want to use Cuda and CuDnn for my project. I am working in a cluster, Cuda is installed in the cluster already (p.s. I don't have root permissions). So I copy the Cuda files into my local folder and install Cudnn as instructed on the official website. However, ld cannot find libcudnn.so.
$ lsb_release -a
Description: Red Hat Enterprise Linux Server release 7.7 (Maipo)
Release: 7.7
What I tried
$ ld -lcudnn --verbose
attempt to open //usr/x86_64-redhat-linux/lib64/libcudnn.so failed
attempt to open //usr/x86_64-redhat-linux/lib64/libcudnn.a failed
attempt to open //usr/lib64/libcudnn.so failed
attempt to open //usr/lib64/libcudnn.a failed
attempt to open //usr/local/lib64/libcudnn.so failed
attempt to open //usr/local/lib64/libcudnn.a failed
attempt to open //lib64/libcudnn.so failed
attempt to open //lib64/libcudnn.a failed
attempt to open //usr/x86_64-redhat-linux/lib/libcudnn.so failed
attempt to open //usr/x86_64-redhat-linux/lib/libcudnn.a failed
attempt to open //usr/local/lib/libcudnn.so failed
attempt to open //usr/local/lib/libcudnn.a failed
attempt to open //lib/libcudnn.so failed
attempt to open //lib/libcudnn.a failed
attempt to open //usr/lib/libcudnn.so failed
attempt to open //usr/lib/libcudnn.a failed
ld: cannot find -lcudnn
If I add the library path of libcudnn.so manually
$ ld -L "$CUDA_HOME/lib64" -lcudnn
attempt to open /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so succeeded
-lcudnn (/home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so)
librt.so.1 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found librt.so.1 at /usr/lib64/librt.so.1
libpthread.so.0 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found libpthread.so.0 at /usr/lib64/libpthread.so.0
libdl.so.2 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found libdl.so.2 at /usr/lib64/libdl.so.2
libstdc++.so.6 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found libstdc++.so.6 at /usr/lib64/libstdc++.so.6
libm.so.6 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found libm.so.6 at /usr/lib64/libm.so.6
libgcc_s.so.1 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found libgcc_s.so.1 at /usr/lib64/libgcc_s.so.1
libc.so.6 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found libc.so.6 at /usr/lib64/libc.so.6
ld-linux-x86-64.so.2 needed by /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so
found ld-linux-x86-64.so.2 at /usr/lib64/ld-linux-x86-64.so.2
ld: warning: cannot find entry symbol _start; not setting start address
Here is my LD_LIBRARY_PATH
$ echo $LD_LIBRARY_PATH
/home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64
ld somehow ignores LD_LIBRARY_PATH. Since I do not have the root permissions, I cannot either create a symbolic link or make changes in ldconfig. So, setting LD_LIBRARY_PATH is the only way I can fix it.
Thanks for your help.
(This could have been a comment but I don't have enough reputation for that; I am talking only about the general linker etc usage, I don't know about the cuda or cudnn projects and what build tools they use, etc)
If I add the library path of libcudnn.so manually
$ ld -L "$CUDA_HOME/lib64" -lcudnn
This is a link line with no object files to link and create an executable with.
attempt to open /home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so succeeded
-lcudnn (/home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64/libcudnn.so)
:
This shows you got the right path into -L.
ld: warning: cannot find entry symbol _start; not setting start address
This will be fixed once you use a proper link line perhaps by incorporating the -L path you have correctly specified above into the build process e.g. the Makefile or whatever else is appropriate.
Here is my LD_LIBRARY_PATH
$ echo $LD_LIBRARY_PATH
/home/ul/ul_student/ul_dco32/pkg/cuda/10.2/lib64
ld somehow ignores LD_LIBRARY_PATH. Since I do not have the root
permissions, I cannot either create a symbolic link or make changes in
ldconfig. So, setting LD_LIBRARY_PATH is the only way I can fix it.
LD_LIBRARY_PATH is not for use by ld at link time, it is for telling ld.so the runtime linker (dynamic loader) where to look when searching for shared libraries to load into the running program.
It turned out to be the problem was the theano configuration. Declaring the full path of CUDA_HOME (or CUDNN_HOME) than using $CUDA_HOME (or $CUDNN_HOME) solved my problem.
[cuda]
root=path/to/cuda/bin
[dnn]
include_path=path/to/cudnn/include
library_path=path/to/cudnn/lib64
P.S. The Cudnn and Cuda modules were installed by the admin, so one big hassle was gone.
wget http://mirror.internode.on.net/pub/OpenBSD/OpenSSH/portable/openssh-7.4p1.tar.gz
wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz
I have tried at least three configurations to install openssl-1.0.2j:
./config
./config --prefix=/usr/local --openssldir=/usr/local/openssl
./config -Wl, -rpath=/usr/local/ssl/lib
After make, make install, it looks like the installation was successful:
It also shows the correct version:
Root # ebd: /usr/local/src/openssh-7.4p1# openssl version -a
OpenSSL 1.0.2j 26 Sep 2016
Built on: reproducible build, date unspecified
Platform: linux-x86_64
...
But when I installe openssh-7.4p1, I got an error:
checking whether snprintf correctly terminates long strings... yes
checking whether vsnprintf returns correct values on overflow... yes
checking whether snprintf can declare const char *fmt... yes
checking whether system supports SO_PEERCRED getsockopt... yes
checking for (overly) strict mkstemp... yes
checking if openpty correctly handles controlling tty... yes
checking whether AI_NUMERICSERV is declared... yes
checking whether getpgrp requires zero arguments... yes
checking OpenSSL header version... 100020af (OpenSSL 1.0.2j 26 Sep 2016)
checking OpenSSL library version... 1000106f (OpenSSL 1.0.1f 6 Jan 2014)
checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your
library. Check config.log for details.
If you are sure your installation is consistent, you can disable the check
by running "./configure --without-openssl-header-check".
Also see contrib/findssl.sh for help identifying header/library mismatches.
I follow the below to install openssh-7.4p1:
tar xf openssh-7.4p1.tar.gz
cd openssh-7.4p1/
./configure --prefix=/opt/openssh-7.4p1 --with-md5-passwords
make && make install
I know that there is a parameter can be used: -with-ssl-dir = PATH.
But I do not want to use it, I would like to know how to add openssl header files and library files to the system environment variables.
The following is the most recently updated message.
I use the following to install the openssh just now.
cd openssh-7.4p1/
CFLAGS="-I /usr/local/openssl/include -L /usr/local/openssl/lib -Wl,-rpath=/usr/local/openssl/lib" ./configure --prefix=/opt/openssh-7.4p1 --with-md5-passwords
make
make install
I get a error.
root#srv13:~/openssh-7.4p1# /opt/openssh-7.4p1/bin/ssh -V
/opt/openssh-7.4p1/bin/ssh: /usr/local/openssl/lib/libcrypto.so.1.0.0: no version information available (required by /opt/openssh-7.4p1/bin/ssh)
/opt/openssh-7.4p1/bin/ssh: /usr/local/openssl/lib/libcrypto.so.1.0.0: no version information available (required by /opt/openssh-7.4p1/bin/ssh)
root#srv13:~/openssl-1.0.2j# which openssl
/usr/bin/openssl
root#srv13:~/openssl-1.0.2j# ls -ld /usr/bin/openssl
lrwxrwxrwx 1 root root 30 Jan 5 21:54 /usr/bin/openssl -> /usr/local/openssl/bin/openssl
root#srv13:~/openssl-1.0.2j#
root#srv13:~/openssl-1.0.2j# ldd /usr/local/openssl/bin/openssl
linux-vdso.so.1 => (0x00007ffcf997f000)
libssl.so.1.0.0 => /usr/local/openssl/lib/libssl.so.1.0.0 (0x00007f1850994000)
libcrypto.so.1.0.0 => /usr/local/openssl/lib/libcrypto.so.1.0.0 (0x00007f1850544000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f185017f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f184ff7b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1850c04000)
root#srv13:~/openssl-1.0.2j# ls /usr/local/openssl/lib/libcrypto.so.1.0.0 -ld
-r-xr-xr-x 1 root root 2690206 Jan 5 21:51 /usr/local/openssl/lib/libcrypto.so.1.0.0
root#srv13:~/openssl-1.0.2j# ldd /opt/openssh-7.4p1/bin/ssh
/opt/openssh-7.4p1/bin/ssh: /usr/local/openssl/lib/libcrypto.so.1.0.0: no version information available (required by /opt/openssh-7.4p1/bin/ssh)
/opt/openssh-7.4p1/bin/ssh: /usr/local/openssl/lib/libcrypto.so.1.0.0: no version information available (required by /opt/openssh-7.4p1/bin/ssh)
linux-vdso.so.1 => (0x00007fff0dbf2000)
libcrypto.so.1.0.0 => /usr/local/openssl/lib/libcrypto.so.1.0.0 (0x00007f57ba287000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57ba083000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f57b9e6a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f57b9c4f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57b988a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f57ba993000)
I know this question has been asked a lot, but the problem remains fo me:
I have a 64bits ELF executable that I am trying to run on my Kali VM, but it keeps telling me that the file doesn't exist.
The solution most of the time for this problem is the difference of architecture, but my Kali is x86-64:
$ uname -m
x86_64
like the file (named '8') that I am trying to execute:
file 8
8: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, BuildID[sha1]=0xf3b096c69086131b091d1805894fde4fae0537a0, stripped
EDIT: Error:
$ chmod +x 8
$ ./8
bash: ./8: No such file or directory
EDIT 2 : lld:
linux-vdso.so.1 => (0x00007fffe37fe000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f680fac8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f680f73c000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f680f343000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f680f13f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f680ef28000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f680fd49000)
I tried to install the 32 bits library to be sure, but it didn't solve anything neither. I also tried it on my Ubuntu, same issues.
Has anybody an idea on ho to run it ? Here is a link to it if some of you want to try on other architectures: https://www.dropbox.com/s/s3ucka4ufd00zmy/8?dl=0
bash: ./8: No such file or directory
This is caused by the file having an elf interpreter which is not installed on your system.
You can find out which elf interpreter your file is compiled with by running
readelf -l ./8 | grep interpreter
I am guessing that you have /lib/ld-linux-x86-64.so.2 compiled in, whereas the standard 64-bit elf interpreter is /lib64/ld-linux-x86-64.so.2.
The best fix is to correct the build script for your executable (it has something like -Wl,--dynamic-linker=/lib/ld-linux-x86-64.so.2 in it).
Alternatively, creating a symlink:
sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib
will also fix the problem.
I installed Qt4 in my local home in a Ubuntu system and the Qt4 libraries are in ~/lib. I have another program (hawkeye for genome assembly) dependent on Qt4 however when I run that it gives the error message:
error while loading share libraries: libQt3Support.so.4: cannot open shared object file: No such file or directory
I checked ~/lib and all the Qt libs are there. Do I need to add the path ~/lib to anywhere?
A good way to debug problems like this is to take a look at the ldd output. For example:
$ ldd yourProg
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e3d000)
libQtGui.so => /usr/lib/libQtGui.so.4.7.0 (0xb7f7f000)
libQt3Support.so => (not found)
...
The above output will tell you if it's picking up your copy of Qt or the system version. Then you can set LD_LIBRARY_PATH or edit ld.so.conf and rerun ldconfig. For example:
$ export LD_LIBRARY_PATH=/path/to/your/qt
$ ldd yourProg
Or (as root):
# echo "/path/to/your/qt" >> /etc/ld.so.conf
# ldconfig
$ ldd yourProg