Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I need to determine whether a library named libunaSA.so is being called directly by the process or by another library called libtoki2.so. I guess what I'm looking for is a pstree for libraries. The system is running RHEL 5.3 Beta.

This output shows the two libraries in the process map

# grep -e toki -e una /proc/2335/maps
0043f000-004ad000 r-xp 00000000 08:02 543465     /usr/lib/libtoki2.so
004ad000-004c5000 rwxp 0006d000 08:02 543465     /usr/lib/libtoki2.so
01185000-01397000 r-xp 00000000 08:02 543503     /usr/lib/libunaSA.so
01397000-013dc000 rwxp 00211000 08:02 543503     /usr/lib/libunaSA.so

This output shows that only the libtoki2.so library is in the current cache

# ldconfig -p | grep -e una -e toki
libtoki2.so (libc6) => /usr/lib/libtoki2.so
libtoki.so.4.4.1 (libc6) => /usr/lib/libtoki.so.4.4.1
libtoki.so.2 (libc6) => /usr/lib/libtoki.so.2

I attached strace to the running process but it doesn't provide much output

# strace -p 2335
Process 2335 attached - interrupt to quit
futex(0xb7ef5bd8, FUTEX_WAIT, 2336, NULL

Here's the output to ldd for each library

# ldd /usr/lib/libtoki2.so
        linux-gate.so.1 =>  (0x00a0a000)
        libdl.so.2 => /lib/libdl.so.2 (0x001bd000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x00f3f000)
        libm.so.6 => /lib/libm.so.6 (0x00b27000)
        libc.so.6 => /lib/libc.so.6 (0x0043d000)
        /lib/ld-linux.so.2 (0x00742000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00110000)
# ldd /usr/lib/libunaSA.so
        linux-gate.so.1 =>  (0x00244000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00baf000)
        libdl.so.2 => /lib/libdl.so.2 (0x007fa000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x009ce000)
        libm.so.6 => /lib/libm.so.6 (0x00c96000)
        libc.so.6 => /lib/libc.so.6 (0x004a2000)
        /lib/ld-linux.so.2 (0x00742000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a9f000)
share|improve this question
This isn't a great answer, but you might be able to infer some part of your answer by starting you process with strace instead of attaching to it once it's already running... –  jj33 Jan 12 '11 at 16:11
You could also try using ltrace instead of strace: both are usable in the exact same situations, but strace tracks calls and ltrace tracks library usage. –  Mei Jan 13 '11 at 22:13

1 Answer 1

up vote 0 down vote accepted

Everything you posted suggests that libunaSA.so stands alone. libtoki2.so does not require libunaSA (as shown by ldd). You could try using ltrace or lsof against the running application to see if libunaSA is called; if libtoki2 makes the call, then it will be hidden (I believe) from the output of ltrace.

lsof will show if the binary requires libunaSA at all.

Both ltrace and lsof are available for RHEL 5.

share|improve this answer
Thank you for introducing me to ltrace. I have opened another question to get it to run in tomcat. serverfault.com/questions/222669 –  flashnode Jan 18 '11 at 18:16
For reference's sake: running ltrace against a complex system like Tomcat is unlikely to avail much: there are too many things going on, too many new processes working in concert. –  Mei Feb 10 '11 at 15:08

Your Answer


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.