12

Assuming I want to test if a library is installed and usable by a program. I can use ldconfig -p | grep mylib to find out if it's installed on the system. but what if the library is only known via setting LD_LIBRARY_PATH?

In that case, the program may be able to find the library, but ldconfig won't. How can I check if the library is in the combined linker path?

I'll add that I'm looking for a solution that will work even if I don't actually have the program at hand (e.g. the program isn't compiled yet), I just want to know that a certain library exists in ld's paths.

  • 2
    You could use ldd <binary> to check if all libraries linked are in the path. Maybe there is a more elegant way. – Thomas May 10 '16 at 9:33
  • @Thomas I think you should make an answer of your comment. ldd serves exactly this purpose. – lgeorget May 10 '16 at 9:41
  • 1
    @Thomas - but what if I the program isn't compiled yet, and that library is needed for compilation? – nbubis May 10 '16 at 9:41
  • @Igeorget - see my edit / comment – nbubis May 10 '16 at 9:44
  • @nbubis: when you need the library for compilation, you normally have to use LIBRARY_PATH environment variable which is looked up e.g. by the gcc compiler. The LIBRARY_PATH environment variable also has a colon seperated list of directories. – Thomas May 10 '16 at 10:09
11

ldconfig can list all the libraries it has access to. These libraries are also stored in its cache.

/sbin/ldconfig -v -N will crawl all the usual library paths, list all the available libraries, without reconstructing the cache (which is not possible if you're a non-root user). It does NOT take into account libraries in LD_LIBRARY_PATH (contrarily to what this post said before edit) but you can pass additional libraries to the command line by using the line below:

/sbin/ldconfig -N -v $(sed 's/:/ /g' <<< $LD_LIBRARY_PATH)
  • ldconfig is a tool from the 1980s that was given up in the 1990s. For this reason, ldconfig is not portable as it only applies to implementations that are based on the SunOS-4.0 a.out based dynamic linker from 1987. – schily May 10 '16 at 10:00
  • How does that help listing libs which are only on LD_LIBRARY_PATH? I guess I could write a script to parse that and then read that through ldconfig, but it seems a bit like an over kill. – nbubis May 10 '16 at 10:10
  • 1
    @nbubis you can always pass the libraries in LD_LIBRARY_PATH to ldconfig. Like /sbin/ldconfig -N -v $(sed 's/:/ /' <<< $LD_LIBRARY_PATH) not too much of an overkill to my taste. – lgeorget May 10 '16 at 10:32
  • @schily Really? It works pretty well with ELF libraries as far as I can tell. And it's still used, ld.so relies on the cache built by ldconfig. – lgeorget May 10 '16 at 10:33
  • The Linux people hacked the old Sun linker source-code to support ELF. The new ELF implementation from Sun removed ldconfig in an agreement with AT&T as the linker caching was too sensitive to errors. Sun later added the tree stooges: moe, lari and crle as helper programs for ELF management. – schily May 10 '16 at 10:52
1

Globally substitute (space) for : with LD_LIBRARY_PATH

/sbin/ldconfig -N -v $(sed 's/:/ /g' <<< $LD_LIBRARY_PATH)
0

You can compile a simple test program with gcc and link your library. Then you can check the used libraries with ldd. I use something like this:

echo "int main(){}" | gcc -x c++ -Wl,--no-as-needed -lmylib - && ldd a.out | grep mylib

-Wl,--no-as-needed prevents the linker from discarding the library, because no symbols from the library are used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.