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 search开发者_开发知识库ing 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.
ThanksIf 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 withLD_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.
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.
- You compile.
- You link - but since these are shared libraries, it doesn't insert all the symbols.
- You now have an executable that depends on the shared libraries to run.
- When you run your executable, the loader loads all the shared libraries before starting the program.
- If it can't find a library, it'll crash your program with the error you saw.
- 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
精彩评论