Compiled C++ program raises "cannot open shared object file" on another system though the file is present

Question

I wrote a tiny program that requires some libraries including libboost_filesystem, libboost_program_options and libcurl.

I compiled it on my home machine and took the binary to my computer at work to test it there. But there it gives the following error message when I try to start the program:

error while loading shared libraries:
libboost_filesystem.so.1.42.0: cannot
open shared object file

But when I search for this file I see that it exists in: /usr/lib/libboost_filesystem.so.1.42.0

Did I something wrong during the compilation / linking of my program? If yes what do I have to do to make it work on other machines?

Hypethral

I often find that ldd can help me find out what's wrong. What does ldd ./your_executable say? – Sandry

From what you have said, it looks like it should be working. There may be a 32 bit vs 64 bit conflict. Try running file ./your_executable and file /usr/lib/libboost_filesystem.so.1.42.0 to check that the architectures match :) – Sandry

wow you are right. the program is built as 32bit and the library present is 64bit – Hypethral

well, mixing 32bit app and 64bit os doesn't work that well :) – Excipient

Answer 1

First, try to issue ldconfig -p | grep libboost_filesystem.so in a console to make sure the library is in your ld cache.

If it is not, you may need to add a file with a name like boost.conf to your /etc/ld.so.conf.d directory. This file should contain a path to your boost libraries. Then run sudo ldconfig to update your system's ld cache.

Hope this will help...

Barley

Answer 2

Did you compile the shared binaries of boost and provided them to the user?

Often boost can be used without any binary/shared to provide. But if you use, for example, boost::filesystem, you'll have to build the binaries, as lib or shared object, and make sure it's available to the final executable shared binary search path.

You can find an explaination and more details in the boost documentation. Here is the linux version : http://www.boost.org/doc/libs/1_44_0/more/getting_started/unix-variants.html

From this page :

Most Boost libraries are header-only: they consist entirely of header files containing templates and inline functions, and require no separately-compiled library binaries or special treatment when linking.

...

The only Boost libraries that must be built separately are:

• Boost.Filesystem
• Boost.GraphParallel
• Boost.IOStreams
• Boost.MPI
• Boost.ProgramOptions
• Boost.Python (see the Boost.Python build documentation before building and installing it)
• Boost.Regex
• Boost.Serialization
• Boost.Signals
• Boost.System
• Boost.Thread
• Boost.Wave

Sebiferous

Could you explain this with more details please? Or lead me to some resource? I am fairly new to linux development and do not know much about it. – Hypethral

I'm adding a link to more precise documentation about that. Done. – Sebiferous

Answer 3

Looks like you need to statically link the library. Here's a good explanation. Boost static linking

Epidaurus

ok but if I link them statically won't I lose the benefit of having dependencies to shared libraries? I thought that would be the "standard" way under linux – Hypethral

Answer 4

Did you link against the same version of the boost_filesystem library? Depending on how you compile your application, it requires the very same version of the library to be present.

You could try to check for what your application actually looks for with:

ldd <your app name>

Probably check your LD_LIBRARY_PATH environment variable as well.

Excipient

lld gave me libboost_filesystem.so.1.42.0 => not found libboost_program_options.so.1.42.0 => not found libboost_system.so.1.42.0 => not found – Hypethral

Answer 5

Could you make sure that /usr/lib/libboost_filesystem.so.1.42.0 is not a dead link ?

Scissor

Answer 6

is /usr/lib in your LD_LIBRARY_PATH environment variable?

Hefty