I am at my wits' end with this issue because I have no idea what is wrong with my compiler. I am trying to run some C++ code using cmake on Ubuntu 21, and I get this error:
error while loading shared libraries: librocksdb.so.6.12: cannot open shared object file: No such file or directory
Now here's the thing: I have rocksdb installed (via apt), but only the following:
ls -l /lib/librocksdb*
-rw-r--r-- 1 root root 21315638 Dec 10 2020 /lib/librocksdb.a
lrwxrwxrwx 1 root root 20 Dec 10 2020 /lib/librocksdb.so -> librocksdb.so.6.11.4
lrwxrwxrwx 1 root root 20 Dec 10 2020 /lib/librocksdb.so.6 -> librocksdb.so.6.11.4
I know the path is the correct one and is recognised by ld since it works with my other shared libraries. There is clearly a version mismatch since my compiler is trying to find 6.12, but I have no idea how to fix it and get the correct version. Things I tried so far:
clearing caches
reinstalling
building from source (does not generate these library names, even with the correct branch)
creating symlinks (still gives me the same error)
setting find_library(rocksdb NAMES librocksdb.so.6 REQUIRED) in my CmakeLists.txt (also tried with 6.11)
What am I doing wrong and why am I getting this error? Any help would be appreciated.
Fixed, I had some old header files under my /include directory and the wrong library was being linked at compile time
I am using CMake to compile an executable that is linked against several libraries that I have built and installed into a local project directory (libs/3rdparty). Note that this is prior to installation of the project, primarily for the purpose of running unit tests and debugging. The problem I am having is that sometimes there is a library that is linked, but the executable is missing the path to the library. The library I am currently having an issue with is leptonica. However, I have run into this issue several times with different libraries on different platforms (osx, fedora, centos, ubuntu). Through research I have seen similar issues, but I have never been able to find a definitive answer of why the full path to the library would be missing.
I've tried playing with:
CMAKE_BUILD_WITH_INSTALL_RPATH
CMAKE_INSTALL_RPATH
CMAKE_INSTALL_RPATH_USE_LINK_PATH
and these don't seem to have much effect.
My CMakeLists contains:
find_package(Leptonica REQUIRED)
target_link_libraries(${target}
PRIVATE
...
${Leptonica_LIBRARIES}
)
Here is the output from ldd on one of the unit test executables:
ldd test_utilities
...
libleptonica.so.5.3.0 => not found
libtesseract.so.4 => {MY PROJECT}/libs/3rdparty/tesseract/lib/libtesseract.so.4
leptonica is the only library that is not found out of ~30 other libraries.
Does anyone know what the root cause of this problem is? I am not looking to work around the problem by modifying LD_LIBRARY_PATH.
-- Added LeptonicaTargets-release.cmake. According to this the full path to the lib should be in the target.
#----------------------------------------------------------------
# Generated CMake target import file for configuration "RELEASE".
#----------------------------------------------------------------
# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)
# Import target "leptonica" for configuration "RELEASE"
set_property(TARGET leptonica APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(leptonica PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "/usr/lib/x86_64-linux-gnu/libpng.so;/usr/lib/x86_64-linux-gnu/libz.so;m"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libleptonica.so.1.77.0"
IMPORTED_SONAME_RELEASE "libleptonica.so.5.3.0"
)
list(APPEND _IMPORT_CHECK_TARGETS leptonica )
list(APPEND _IMPORT_CHECK_FILES_FOR_leptonica "${_IMPORT_PREFIX}/lib/libleptonica.so.1.77.0" )
# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)
Here are the files in the leptonica/lib directory:
ll libs/3rdparty/leptonica/lib/
total 2776
drwxr-xr-x 3 user user 4096 May 30 14:17 ./
drwxr-xr-x 5 user user 4096 May 30 14:17 ../
lrwxrwxrwx 1 user user 21 May 30 14:17 libleptonica.so -> libleptonica.so.5.3.0
-rw-r--r-- 1 user user 2829784 May 30 09:49 libleptonica.so.1.77.0
lrwxrwxrwx 1 user user 22 May 30 14:17 libleptonica.so.5.3.0 -> libleptonica.so.1.77.0
drwxr-xr-x 2 user user 4096 May 30 14:17 pkgconfig/
Output from chrpath --list test_utilities appears to contain the correct path to the library as well:
chrpath --list test_utilities
test_utilities: RUNPATH=...:{MY PROJECT}/libs/3rdparty/leptonica/lib:...
For anyone who runs across this, I have finally figured it out.
The issue was related to the library being a transitive dependency of OpenCV. On Ubuntu, ld now defaults to using using --enable-new-dtags which uses RUNPATH, not RPATH. There is an issue where RUNPATH is not searched for transitive dependencies.
See https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638
Simply adding "-Wl,--disable-new-dtags" to the target linker options resolved my issue. All libraries are now found, including other libraries than leptonica that I added today. I am sure that I will likely have to make changes when building a package for installation though.
I tried to run a program that requires log4cpp,
I got following error when I try to run the program
error while loading shared libraries: liblog4cpp.so.4: cannot open shared object file: No such file or directory
I have set the library path in $LD_LIBRARY_PATH and these are the files in my /usr/local/lib directory:
liblog4cpp.a
liblog4cpp.so
liblog4cpp.so.5.0.6
liblog4cpp.la
liblog4cpp.so.5
pkgconfig
What could be the problem here ?
Thanks!
Use
ldd [program name]
so see what's actually loaded (assuming you are on a Unix system since you use LD_LIBRARY_PATH).
I'm a little confused as to what's happening here, when I'm our shared computer I can run our program, but when I ssh in from my house to restart it I get an exception
$ ./jsonparser
./jsonparser: error while loading shared libraries: libjansson.so.4: cannot open shared object file: No such file or directory
Is there some other way I should launch the app?
libjansson is installed to /usr/local/lib:
$ ls /usr/local/lib
libjansson.a libjansson.la libjansson.so libjansson.so.4 libjansson.so.4.6.0
Maybe /usr/local/lib is not in your Library pathg ( LD_LIBRARY_PATH I guess )? Or maybe there is a dependency for libjansson.so.4 is not resolved? By using ldd ./jsonparser ldd tries to load all dependent .so-file. Hopefully this will give you some more information about your issue.
I'm trying to get my Cuda SDK samples running, but I get the following error:
./bandwidthTest: error while loading shared libraries:
libcudart.so.4: cannot open shared object file:
No such file or directory
Why can I compile the example successfully, but not run it? Is there a way to specify the path to the CUDA runtime library manually?
try:
32-bit: sudo ldconfig /usr/local/cuda/lib
64-bit: sudo ldconfig /usr/local/cuda/lib64
cheers
First these that you need is to concatenate the paths to the CUDA binaries and libraries. This is simply done by adding the following lines to your .bashrc file.
export PATH=$PATH:/usr/local/cuda/bin
export LD_LIBRARY_PATH=:/usr/local/cuda/lib64
If you are using a 32-bit operating system change lib64 to lib
Second, there should have been some shared object files installed in /usr/lib or /usr/lib64, depending on your operating system. These object files should be contained in a directory called "nvidia". The two files we are concerned with are names libcuda.so.drivernumber and libOpenCL.so.somenumber. To differentiate between the actual shared object files just use ls -l. The symbolic links will show what they are actually linking to.
As root, execute the following commands:
ln -s /usr/lib64/nvidia/libcuda.so.somenumber /usr/lib64/libcuda.so
ln -s /usr/lib64/nvidia/libOpenCL.so.somenumber /usr/lib64/libOpenCL.so
That should allow you to compile all the sources in the SDK.
As of Cuda 5.5 and Ubuntu 12.04/12.10, the command above becomes (notice the Ubuntu and Cuda directory changes) for 64bit
ln -s /usr/local/cuda/lib64/libcuda.so.5.5 /usr/lib/libcuda.so.5.5
That is, the lib folders on Ubuntu as of 12.04 are lib32 and lib; the 64 is implicit, and cuda 5.5 and greater now installs to a different directory.
1 error while loading shared libraries: libcudart.so.6.0: cannot open shared object file: No such file or directory
32-bit: sudo ldconfig /usr/local/cuda/lib
64-bit: sudo ldconfig /usr/local/cuda/lib64
(refer: http://blog.csdn.net/shenchong721/article/details/21529295)
Works for me!
LD_LIBRARY_PATH is strongly deprecated. It may mess up other programs, and others may reset it. It should only be used to temporarily override the permanent paths for testing purposes (don't take my word, google it).
Instead, add a line with your cuda lib directory on it to /etc/ld.so.conf, after any existing lines.
For example, if you installed on /usr/local/cuda, you will need to add
32-bit : /usr/local/cuda/lib
64-bit : /usr/local/cuda/lib64
Save, and run ldconfig. This should permanently fix the problem.
The symbolic links are probably already set up by the installation. If not, then add them as Alex advised.
Note - I received errors referencing /lib, but I needed to add lib64 to fix them.
create a nvidia_settings.conf file in /etc/ld.so.conf.d/ and add the path to the libs in the file nvidia_settings.conf
/usr/local/cuda/lib64
/usr/local/cuda/lib
Now to update the changes run the following command:
sudo ldconfig
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib
or if you are running cuda-5.0 on a 64-bit machine
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-5.0/lib64
the system find library with ld tool. as the top answer says, 64-bit: sudo ldconfig /usr/local/cuda-xx/lib64 ;;xx is the cuda libraryedition
In my case I was running an application using MPI. The error was:
libcudart.so.7: cannot open shared object file
CUDA was properly installed in all nodes. Also, as in the previous answers, the variables $PATH and $LD_LIBRARY_PATH were pointing to the binary and libraries respectively.
Passing the $PATH and $LD_LIBRARY_PATH in the MPI command solved the issue.
mpirun -x PATH=$PATH -x LD_LIBRARY_PATH=$LD_LIBRARY_PATH ...