0

I am working on a C++ project consisting of multiple similar programs. Each use a variety of headers and binaries, around 80. I managed to compile each program, and successfully run each but one of them, one named VerifyServer. When I try to run this, I get the below error:

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

However, here's the weird thing:

I was getting a very similar error when I tried running the other programs as well, but then I added

-Wl,-rpath=$(BOOST_LIB_HEADER_PATH)/stage/lib

to each of my compiler arguments, and it worked. I managed to run each programm, and even the file indicated in the error message of VerifyServer changed. Note that the variable BOOST_LIB_HEADER_PATH is correctly assigned to the path of my boost libraries.

Since my run time linker was failing to find this binary to correctly link it with my program, I tried checking which dependencies it was unable to find, so when I ran

ldd VerifyServer | grep boost (I use grep for simplicity)

I get this message:

libboost_thread.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_thread.so.1.57.0 (0x00007f34c9b36000)
libboost_serialization.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_serialization.so.1.57.0 (0x00007f34c9ad1000)

libboost_system.so.1.57.0 => not found

So, by now I assume that the system binary is not in the same directory as the others. When I manually check, I see that oddly enough, it is right there! So I decide to do the same thing on one of the programs that run without any problems, and I use

ldd IdentityProviderServer | grep boost

and I get the following message:

libboost_thread.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_thread.so.1.57.0 (0x00007f97b6094000)

libboost_serialization.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_serialization.so.1.57.0 (0x00007f97b602f000)

libboost_system.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_system.so.1.57.0 (0x00007f97b602a000)

libboost_filesystem.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_filesystem.so.1.57.0 (0x00007f97b600d000)

When I see that the system binary can be found in the same location as others, I just get confused. I don't know what the issue is here. Is there something I am missing about how the linker works?

Please note that I have to use the version 1.57.0 of boost here. I cannot update it to the current version, and I doubt my issue has anything to do with the version of boost.

Levent
  • 25
  • 4

1 Answers1

0

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.

g-radam
  • 527
  • 1
  • 7
  • 20