Re: [sleuthkit-developers] error loading shared libraries

[Stuart M. <st...@ap...>]

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