Error While Loading Shared Libraries: Libboost_System.So.1.45.0: Cannot Open Shared Object File: No Such File or Directory

error while loading shared libraries: libboost_system.so.1.45.0: cannot open shared object file: No such file or directory

The library cannot be found.

Libraries are by default looked for in /lib, /usr/lib and the directories specified by /etc/ld.so.conf.

Usually system libraries (like boost, if you installed it via your package manager) are located in /usr/lib, but it's probably not your case.

Where are your boost libraries located on your system? Did you compile them by yourself? In this case you should tell the dynamic linker to look for your libraries in the directory they're located by using the LD_LIBRARY_PATH environment variable:

LD_LIBRARY_PATH="your/boost/directory" ./testfgci

I'd suggest you to install boost libraries using your package manager, anyway, this will make your life a lot simpler.

error while loading shared libraries: libboost_system.so 1.49.0: No such file or directory

As stated above, the -static option was neededd.

Error loading shared libraries of boost

How did you install the boost libraries?

The problem you're likely having is that the linker can not find the libraries, and when you built your program, you had to manually specify additional library paths to search for libraries.

A quick fix you can do is to set LD_LIBRARY_PATH to include the directory where the boost thread library is:

export LD_LIBRARY_PATH=/path/to/boost/libs:$LD_LIBRARY_PATH

./runExecutable

Error while loading shared libraries: libboost_iostreams.so.1.59.0: cannot open shared object file: No such file or directory

Let's assume your library is being exist but not in standard paths and you're getting this error while running a binary. In this case you could try to set the LD_LIBRARY_PATH environment variable to point to the directory where the library is located. Then the loader will search for the library in the given path.

export LD_LIBRARY_PATH=/path/to/my/library
./run_my_binary

caffe can't find libboost_system.so.166.0

Your /usr/local/lib/libboost_system.so.1.66.0 is evidently one you built
yourself and want the loader to find at runtime without special measures.

But having built it, you didn't update the ldconfig cache
(because you didn't know you had to); so the runtime loader is not yet aware that this
library exists and can't find it.

When the loader is looking for the shared libraries needed to assemble a new process,
it does not search all of the linker's default search directories. That would be slow.
By default it searches a cached database /etc/ld.so.cache, of libraries that were
found by ldconfig, last time it was run.

By default, ldconfig caches libraries that it finds in /lib, /usr/lib and in the directrories
listed in the file /etc/ld.so.conf, and/or any similar *.conf files that are recursively include-ed in /etc/ld.so.conf.
For example:

$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

$ cat /etc/ld.so.conf.d/*.conf
/usr/lib/x86_64-linux-gnu/libfakeroot
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/nvidia-384
/usr/lib32/nvidia-384
/usr/lib/nvidia-384
/usr/lib32/nvidia-384
# Legacy biarch compatibility support
/lib32
/usr/lib32

You see that /usr/local/lib is listed there. So, to make the loader aware
of your new /usr/local/lib/libboost_system.so.1.66.0, just run:

ldconfig

as root. You need to do likewise anytime you install a new locally built
shared library in /usr/local/lib.

If you want the loader to find a shared library /a/b/libfoo.so that isn't in the ldconfig
cache, you can get it to do so by the special measure of appending /a/b/libfoo.so to the value of the
environment variable LD_LIBRARY_PATH (which by default is empty) in the environment in which you launch
the process that needs to load that library. The loader will search the LD_LIBRARY_PATH
directories, if any, before the ldconfig cache. However, not adding a shared library
to the ldconfig cache should be an informed choice and setting LD_LIBRARY_PATH
is, of course, not well motivated merely by ignorance of the ldconfig apparatus or of the linker's -rpath option

Run-time linker issue: error while loading shared libraries

This may be due to the linker unable to find transient dependencies. If you are directly linking against EG: libboost_thread, then the applications runtime linker will use the -rpath path that you defined when compiling.

HOWEVER, the libboost_thread may require ITS OWN library, libboost_system. The question is, should the libboost_thread library's runtime linker use your applications -rpath? or ignore it and use its own system search paths?? You must explicitly tell the runtime linker what it should do. Note, the default runtime linker search behavior changes depending on your compiler version. Google, RUNPATH vs RPATH and -Wl,--disable-new-dtags

I have answered this issue in another similar question: CMake project fails to find shared library

Although that user is using CMake to build their application, the underlying problem may be occurring here too.

---

Related Topics