I met the share library not found on the head node of a cluster with torch. I have built the library as well as specify the correct path of the library while compiling my own program "absurdity" by g++. So it looks strange to me. Any idea? Thanks and regards!
[tim#user1 release]$ make
...
...
g++ -pipe -W -Wall -fopenmp -ggdb3 -O2 -I/home/tim/program_files/ICMCluster/ann_1.1.1/include -I/home/tim/program_files/ICMCluster/libsvm-2.89 -I/home/tim/program_files/ICMCluster/svm_light -o absurdity xxxxxx.o -L/home/tim/program_files/ICMCluster/ann_1.1.1/release/lib -L/home/tim/program_files/ICMCluster/libsvm-2.89/release/lib -L/home/tim/program_files/ICMCluster/svm_light/release/lib -lm -ljpeg -lpng -lz -lANN -lpthread -lsvm -lsvmlight
[tim#user1 release]$ ./absurdity
./absurdity: error while loading shared libraries: libsvmlight.so: cannot open shared object file: No such file or directory
[tim#user1 release]$ ls /home/tim/program_files/ICMCluster/svm_light/release/lib/libsvmlight.so -l
-rwxr-xr-x 1 tim Brown 121407 Jan 31 12:14 /home/tim/program_files/ICMCluster/svm_light/release/lib/libsvmlight.so
[tim#user1 release]$ LD_LIBRARY_PATH= /home/tim/program_files/ICMCluster/svm_light/release/lib:$LD_LIBRARY_PAT
[tim#user1 release]$ export LD_LIBRARY_PATH
[tim#user1 release]$ ./absurdity
./absurdity: error while loading shared libraries: libsvmlight.so: cannot open shared object file: No such file or directory
[tim#user1 release]$ ls /home/tim/program_files/ICMCluster/svm_light/release/lib
libsvmlight.a libsvmlight.so
Copied from my answer here: https://stackoverflow.com/a/9368199/485088
Run ldconfig as root to update the cache - if that still doesn't help, you need to add the path to the file ld.so.conf (just type it in on its own line) or better yet, add the entry to a new file (easier to delete) in directory ld.so.conf.d.
Your LD_LIBRARY_PATH doesn't include the path to libsvmlight.so.
$ export LD_LIBRARY_PATH=/home/tim/program_files/ICMCluster/svm_light/release/lib:$LD_LIBRARY_PATH
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib).
Generally package manager takes care of this while installing the new library, but not always (specially when you install library with cmake).
And if the output of this is empty
$ echo $LD_LIBRARY_PATH
Please set the default path
$ LD_LIBRARY_PATH=/usr/local/lib
When working on a supercomputer, I received this error when I ran:
module load python/3.4.0
screen
python
To resolve the error, I simply needed to reload the module in the screen terminal:
module load python/3.4.0
python
Related
I am trying to compile and run a C++ program on a server where I don't have root access. I am having trouble linkingboost_iostreams library.
I can successfully compile my program by pointing to the boost installation directory using the -L flag as:
g++ -I path/to/boost/build/include -o out prog1.cpp prog2.cpp -L path/to/boost/build/lib -lboost_iostreams
However, if I run the program as ./out I get the error error while loading shared libraries: libboost_iostreams.so.1.67.0: cannot open shared object file: No such file or directory since the linker is not able to locate libboost_iostreams.so.1.67.0 (which DOES exist under path/to/boost/build/lib)
Thanks to this answer, I was able to explicitly specify LD_LIBRARY_PATH and run the program as
LD_LIBRARY_PATH="path/to/boost/build/lib" ./out.
Since I am not root, I can't run ldconfig either. I was wondering if there is a way to load dynamic libraries without having to prefix LD_LIBRARY_PATH when you run the program and no root access.
I have figured out a way to solve this using the method explained here https://amir.rachum.com/blog/2016/09/17/shared-libraries/. The solution is to use rpath during compilation.
According to the article The only difference between rpath and
runpath is the order they are searched in. Specifically, their
relation to LD_LIBRARY_PATH - rpath is searched in before
LD_LIBRARY_PATH while runpath is searched in after. The meaning of
this is that rpath cannot be changed dynamically with environment
variables while runpath can.
In short once you compile with -rpath path/to/boost/build/lib, the directory containing the library libboost_iostreams.so.1.67.0 is searched at runtime without having to prefix LD_LIBRARY_PATH="path/to/boost/build/lib" ./out.
After compiling with
g++ -I path/to/boost/build/include -o out prog1.cpp prog2.cpp -L path/to/boost/build/lib -lboost_iostreams -rpath path/to/boost/build/lib
I was able to run ./out without any issues.
EDIT 1
As pointed by Nikos in the comments, alternatively you can set your LD_LIBRARY_PATH by export LD_LIBRARY_PATH=path/to/boost/build/lib. Add this line to .~/.bashrc file so that it is not lost when you log out.
I have downloaded and build boost_1_68_0 from source and got the following message:
The Boost C++ Libraries were successfully built!
The following directory should be added to compiler include paths:
/resources/boost_1_68_0
The following directory should be added to linker library paths:
/resources/boost_1_68_0/stage/lib
The code compiles fine with this:
g++-4.9 -std=c++11 -I /resources/boost_1_68_0 -L /resources/boost_1_68_0/stage/lib regex.cpp -lboost_regex -o reg
When I'm trying to run the code I get this:
./reg: error while loading shared libraries: libboost_regex.so.1.68.0:
cannot open shared object file: No such file or directory
However, inside /resources/boost_1_68_0/stage/lib I do have the following files:
libboost_regex.so.1.68.0
libboost_regex.so -> libboost_regex.so.1.68.0
Is there a way to make it look for the shared object inside the /resources/boost_1_68_0/stage/lib direcotory?
Thank you!
Using CentOS 7
Assuming you have root access on the machine, try:
echo "/resources/boost_1_68_0/stage/lib" >> /etc/ld.so.conf.d/boost.conf
and re-run ldconfig.
You have to put /resources/boost_1_68_0/stage/lib in LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=/resources/boost_1_68_0/stage/lib:${LD_LIBRARY_PATH}
Update: issue is solved. The library was Made for Armv7a CPUs but it was "soft float" Not "hard float". It seems like my machine is HF and Not SF compatible
My program depends on an externally build .so library called libMyLib.so. When I compile the program like this:
$ g++ -std=c++11 main.cpp -o run -pthread
it reports that there are a lot of undefined references, obviously because i didn't include libMyLib.so when compiling. So the compiler knows what he needs to compile the program. When i compile the program like this:
$ g++ -std=c++11 main.cpp -o run -pthread -lMyLib
it doesn't report any errors and creates the file "run". Notice that libMyLib.so is already in /usr/local/lib and it looks like it is linked when compiling since the references are defined now and the "run" file is created. But as i run the file, this happens:
$ ./run
./run: error while loading shared libraries: libMyLib.so: cannot open shared object file: No such file or directory
I've checked with ldd and it shows me this:
$ ldd run
...
libMyLib.so => not found
...
So ldd doesn't find the library on execution, but it finds it while compiling. I'm quite new to Linux and linking libraries so i don't know what to do.
Also, running ldd on the .so file returns this:
$ ldd /usr/local/lib/libMyLib.so
not a dynamic executable
I've already checked an this message may occur when running a .so file on the wrong platform. But i've checked, the library is compiled for arm (I'm running on a raspberry pi -> arm):
$ objdump -f /usr/local/lib/libMyLib.so | grep ^architecture
architecture: arm, flags 0x00000150:
I also update the linker:
$ sudo ldconfig -v
...
/usr/local/lib:
libwiringPi.so -> libwiringPi.so.2.44
libwiringPiDev.so -> libwiringPiDev.so.2.44
libMyLib.so -> libMyLib.so.1
...
I really have no clue why this might still happen. Can anyone help me?
/usr/local/lib is one of the directories that the linker searches by default
for libraries specified with the -l option, so your linkage succeeds.
At runtime however, the program loader by default searches for the linked
libraries in:-
/lib, /usr/lib and among the libraries whose names and locations have been cached in the ldconfig cache, /etc/ld.so.cache.
The directories listed in the value of the environment variable LD_LIBRARY_PATH,
in the current shell.
The ldconfig cache is only updated when ldconfig is run. See man ldconfig.
The loader fails to find libMyLib.so at runtime because you have not
run ldconfig since you placed that library in /usr/local/lib and
neither have you correctly added /usr/local/lib to the LD_LIBRARY_PATH
in the same shell in which you try to run the program.
It is inconvenient and otherwise undesirable to require a special setting of
LD_LIBRARY_PATH to enable a program to run.
To enable the loader to find your library, run ldconfig as root. This
will succeed provided that /usr/local/lib is listed in /etc/ld.so.conf,
or in one of the files included by /etc/ld.so.conf. If it's not, then
you can explicitly cache the shared libraries from /usr/local/lib by running
ldconfig /usr/local/lib, as root.
First check LD_LIBRARY_PATH variable is having the path to your library directory
$ echo $LD_LIBRARY_PATH
If not there then update the library path.
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
Use strace to debug.
strace -f ./run
I built GLEW (using make install) to use in a small test program I am writing (source can be found here if you need it). I ran locate libGLEW.so just to check if the GLEW libraries were properly installed, and got the following output:
/usr/lib64/libGLEW.so
/usr/lib64/libGLEW.so.2.0
/usr/lib64/libGLEW.so.2.0.0
This was completely normal. I then compiled it using the command:
g++ main.cpp -o main -lglfw -lGLEW -lGL -lX11 -lpthread -lXi -g
This also threw up no errors. However, when I tried to execute the program:
./main: error while loading shared libraries: libGLEW.so.2.0: cannot open shared object file: No such file or directory
Just for a sanity check, I ran ldd main | grep "GLEW", and sure enough:
libGLEW.so.2.0 => not found
I initially thought that this could be a problem with the linker not searching the directory containing the libraries. So I ran the command ld --verbose | grep "/usr/lib64" and there was a SEARCH_DIR containing the required directory:
... SEARCH_DIR("=/usr/lib64"); ...
This was especially confusing. I tried compiling with the -L/usr/lib64 option, but the same error message still persisted. I checked that the symlinks to the library were correct and they were:
lrwxrwxrwx 1 root root 16 Jul 15 10:22 libGLEW.so -> libGLEW.so.2.0.0
lrwxrwxrwx 1 root root 16 Jul 15 10:38 libGLEW.so.2.0 -> libGLEW.so.2.0.0
-rw-r--r-- 1 root root 707K Jul 15 10:22 libGLEW.so.2.0.0
I am not sure what exactly is causing the issue but I'm starting to believe that I didn't install the libraries correctly. I feel like the answer is right in front of my eyes but I can't find it.
Thanks in advance for any help.
Debian and Ubuntu do not install system libraries into /usr/lib64, and the installation instructions you used are wrong for those systems. (It is not a good idea to install libraries bypassing the packaging system into /usr anyway.) /usr/local/lib is searched by default (unlike other systems), so you could move the libraries to that directory.
Compile with -Wl,-rpath=/usr/lib64
I know that a similar question has been asked before, but none of the suggestions have helped.
I am trying to compile an OpenCV project using C++ in Ubuntu 15.10. I can run the project correctly in Netbeans. But I am supposed to send this to someone who will be using the command line. I can compile the program with the line:
g++ -ggdb -o convert *.cpp \`pkg-config --cflags --libs opencv\`
Where convert is the chosen name for the executable. There are no problems after executing this line. But when I run
./convert "image1.tif" "image2.tif"
I get:
./convert: error while loading shared libraries: libopencv_imgcodecs.so.3.2: cannot
open shared object file: No such file or directory
In my .cpp files, I have:
#include "/usr/local/include/opencv2/highgui/highgui.hpp"
The file libopencv_imgcodecs.so.3.2 is in my /usr/local/lib folder. I tried putting -L/usr/local/lib in the command line, but this did not help. Perhaps this file path needs to go in a specific order in the command line? The order mattered for the pkg-config --cflags --libs opencv, which had to come after the -o convert *.cpp.
Just for convenience, as the first comment said, you just need:
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib
if your CMAKE_INSTALL_PREFIX=/usr/local
Your libopencv_imgcodecs.so isn't linked correctly. You can check that by using ldd:
$ ldd ./convert
/path/to/program/convert:
...
libopencv_imgcodecs.so.3.2 => not found
libopencv_imgproc.so.3.2 => not found
libopencv_core.so.3.2 => not found
...
You can find where libopencv_imgcodecs.so is installed:
$ find / -type f -name libopencv_imgcodecs.so.3.2
/usr/local/lib/libopencv_imgcodecs.so.3.2
Save this directory to LD_LIBRARY_PATH variable.
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib