C++: How to link a library, located in my project folder?

Question

Hi,

I'm using Linux and Eclipse.
I want to use a library (Box2D). I have the lib-file "libBox2D.so.2.1.0". I put it in a self-made lib folder in my project folder (also the working directory for the executable).
I added -lBox2D to the linker command-line arguments. (This means I added "Box2D" as library in the Eclipse GUI).

But when I try to run it, my application prints automaticly that he cannot find the "libBox2D.so.2.1.0" library file with the following message:

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

I think he is searching for this library in /usr/lib/....

So: How can I tell the compiler/linker/"whatever-that-needs-to-know-it" that my application has to look for the library at the relative path "lib/libBox2D.so.2.1.0" (relative to the working dir)?

Maybe: Can the problem be that on the download page of Box2D (the link here above), they say it is version 2.1.2 and that library is version 2.1.0 (if I look to the soname)?

PS: I also tried to put it in the root of my project folder, but it didn't succeed...

Any help would be very appreciated.
Thanks

Answer 1

You need to set the LD_LIBRARY_PATH environmental variable.

I should add that this shouldn't normally be necessary to ship products, but is 'fine' for development. Read Why LD_LIBRARY_PATH is bad.

And, for a little background, it's the "loader" that needs it. So set it before running your program.

1. You compile.
2. You link - but since these are shared libraries, it doesn't insert all the symbols.
3. You now have an executable that depends on the shared libraries to run.
4. When you run your executable, the loader loads all the shared libraries before starting the program.
5. If it can't find a library, it'll crash your program with the error you saw.
6. You can give it a list of paths to search by setting LD_LIBRARY_PATH.

Use it like this:

export LD_LIBRARY_PATH=/path/to/dir
./path/to/executable

Answer 2

If you are just trying out a new library, then using LD_LIBRARY_PATH during development is fine. In fact, this is the most appropriate use of LD_LIBRARY_PATH. If you are looking for advice on how to design and deploy shared components, then read on.

If your goal is for your application to load the shared library from a location relative to the application, then you probably should look into adding runtime link path information into your executable when you link it. The runtime loaded uses a few different mechanisms for locating shared and dependent objects when the application is loaded.

• The most common method is to include full path names for shared libraries. This is what most linkers do by default.
• Another method is to include only the library names and have the loader search configured runtime paths (e.g., those set by ldconfig, those configured with LD_LIBRARY_PATH, etc.).
• The method that you are looking for is to encode a relative runtime search path

The last option is implemented differently depending on OS and compiler choices. I'm guessing that you are using the GNU toolchain on a Linux box, so take a look at the ld -rpath option. There are a few good examples out there - Avoiding LD_LIBRARY_PATH mentions ld -rpath '$ORIGIN/../lib' as an option, Dynamic Libraries, RPATH, ... discusses a bunch of interesting information related to runtime path configuration.