I’m having problems with
The link line looks like this when I run make (this is a Linux system using g++ version 4.1.x):
<code>g++ a.o b.o c.o -o myapp \ -L/long/path/to/libs/ \ -L/another/long/path/ \ -labc -ldef -lghi </code>
If I remove the directories from
<code>/usr/bin/ld: cannot find -labc </code>
On the other hand, if I remove the directories from the list of
<code>/usr/bin/ld: warning: libabc.so, needed by /long/path/to/libs/libxyz.so, not found (try using -rpath or -rpath-link) </code>
and then many more errors, such as:
<code>/long/path/to/libs/libdef.so: undefined reference to `Foo::Bar<Baz>::junk(Fred*)' </code>
Can someone explain the difference between
Also, what do I have to add to the link line to avoid using
EDIT: When directories were missing from
The settings of LD_LIBRARY_PATH has the highest precedence, so when it is set, the set of directories mentioned by LD_LIBRARY_PATH are searched first even before the standard set
Though setting of LD_LIBRARY_PATH help with debugging and to try out a newer version of
Also refer this HOWTO from Linux Documentation for more details on Shared Libraries
LD_LIBRARY_PATH is intended for finding shared libraries when running an application. It is a side effect that it’s impacting your link, and you should not rely on that.
There are two answers to this question, part of the answer lies in the compile-time linking (i.e gcc -lfoo -L/usr/lib … which in turn calls ld), and run-time linker lookups.
When you compile your program, the compiler checks syntax, and then the linker ensures that the symbols required for execution exist (i.e variables / methods / etc), among other things. LD_LIBRARY_PATH, as has been noted, has the side-effect of altering the way gcc/ld behave as well as the way the the run-time linker behaves by modifying the search path.
When you run your program, the run-time linker actually fetches the shared libraries (on disk or from memory if possible), and loads in the shared symbols / code / etc. Again, LD_LIBRARY_PATH affects this search path implicitly (sometimes not a good thing, as has been mentioned.)
The correct fix for this without using LD_LIBRARY_PATH on most Linux systems is to add the path that contains your shared libraries to /etc/ld.so.conf (or in some distributions, create a file in /etc/ld.so.conf.d/ with the path in it) and run ldconfig (/sbin/ldconfig as root) to update the runtime linker bindings cache.
Example on Debian:
<code>jewart@dorfl:~$ cat /etc/ld.so.conf.d/usrlocal.conf /usr/local/lib </code>
Then when the program is executed, the run-time linker will look in those directories for libraries that your binary has been linked against.
If you want to know what libraries the run-time linker knows about, you can use:
<code>jewart@dorfl:~$ ldconfig -v /usr/lib: libbfd-126.96.36.19980103.so -> libbfd-188.8.131.5280103.so libkdb5.so.4 -> libkdb5.so.4.0 libXext.so.6 -> libXext.so.6.4.0 </code>
And, if you want to know what libraries a binary is linked against, you can use ldd like such, which will tell you which library your runtime linker is going to choose:
<code>jewart@dorfl:~$ ldd /bin/ls linux-vdso.so.1 => (0x00007fffda1ff000) librt.so.1 => /lib/librt.so.1 (0x00007f5d2149b000) libselinux.so.1 => /lib/libselinux.so.1 (0x00007f5d2127f000) libacl.so.1 => /lib/libacl.so.1 (0x00007f5d21077000) libc.so.6 => /lib/libc.so.6 (0x00007f5d20d23000) </code>
If I were to guess, I would say that the linker is falling back to using