Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Is there a GNU Linux built-in for getting a list of the filenames of shared libraries? I have considered parsing the output of ldconfig -p. However, I'm not sure about consistency in output from system to system.

I am already aware that I could use find but given that the linker / loader has a cache of libraries and locations, it seems more efficient to use it in some way. Additionally, the paths that the linker / loader searches are the only ones I'm concerned with--i.e libraries that have been processed by ldconfig.

share|improve this question
add comment

1 Answer 1

up vote 4 down vote accepted

If you want to catch them all, there is no other choice but to do full filesystem traversals. ldconfig knows only about the libraries in the standard paths and the extra paths it is configured to look in (usually defined in /etc/ld.so.conf*). The usual suspect places where other libraries can be found are $HOME and /opt, though there is no limit, especially when people build applications themselves.

If you don't trust the output of ldconfig -p, you can parse its cache directly. It's binary, but using strings removes all the garbage (5 so /lib/ matches):

strings -n5 /etc/ld.so.cache

On my system, they both give the same results, which I verified with this quicky:

a=$(ldconfig -p | awk -F'> ' '{print $2}' | sort); # get them to the same format
b=$(strings -n5 /etc/ld.so.cache | sort -u); 
echo -e "$a\n$b\n$b" | sort | uniq -u

Which checked if any library on the ldconfig -p list was not mentioned in the cache. Nothing was returned.

share|improve this answer
    
lynxlynxlynx, I appreciate your thoughts and I understand that perspective. I should limit the scope of my question--I'll edit for clarity. In this case, we are concerned primarily with what ldconfig knows about. –  ephsmith Jul 16 '12 at 16:58
1  
I hope it is not a security measure, since you have LD_LIBRARY_PATH, LD_ADD and probably others that can practically circumvent the original list. –  lynxlynxlynx Jul 16 '12 at 17:29
    
You bring up a good point. This is not a security measure. It's one approach in an effort to support some legacy scripts that depend libs that could be in one of several different locations. –  ephsmith Jul 16 '12 at 17:48
    
Great update! Parsing the cache directly this way really helps. –  ephsmith Jul 16 '12 at 21:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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