There are two parts to getting a binary with shared libraries to work.
The first is the BUILD. For any routine you use, just must tell the
linker where it is, and this step uses the -L and -l options:
gcc -o myApp myApp,o -L/path/to/libs -lfoo
for some shared library /path/to/libs/libfoo.so
That has to work, else the linker will complain of unresolved dependencies.
But that's only half the story. The build link step merely embeds the
simple string 'libfoo.so' in the binary.
Now you got to RUNTIME and the link-loader has to find a file libfoo.so,
but obviously does NOT use, or know anything about, the -L, -l options
of the build step. The BUILD and RUN steps can be on different hosts of
course.
Instead, the link-loader looks for libfoo.so according to directories in
LD_LIBRARY_PATH, if set, and in standard directories like /lib, /usr/lib
etc. I think there is some kind of cached list too, and ldconfig can
query this list.
A useful command is ldd, it tells you all runtime dependenices, and
whether the link-loader would be able to resolve them
$ ldd myApp
Hope this helps
Stuart
|
