views:

269

answers:

2

Short: I'm looking for something that will list all unresolved dependencies in an SO, taking into account the SOs that are in it's dependencies.

Long:

I'm converting a lot of static-compiled code to Shared Objects in Linux- is there an easy way to determine what other SOs my recently compiled SO is dependent on besides trial & error while trying to load it?

I'm sure there is a better way, but I haven't been able to find it yet.

I've found "ldd", but that only lists what the SO says it's dependent on. I've also used "nm" to figure out once an SO fails to load to verify what other SO contains it.

A: 

I don't have code for you, but I can give pointers:

It's just a graph problem. You should use objdump -T to dump the dynamic symbol table for a given binary or shared object. You'll see many lines of output, and the flags can be a little confusing, but the important part if that symbols will either be *UND* or they'll have a segment name (.text etc).

Any time you see *UND*, that means that it's an undefined symbol which has to be resolved. Defined symbols are the targets of resolution.

With that, and a little Python, you should be able to find what you need.

agl
+1  A: 

"ldd -r foo.so" should print the set of symbols which foo.so needs but which aren't provided by its direct dependencies.

Alternatively, link foo.so like this:

  gcc -shared -o foo.so foo.o bar.o -ldep1 -ldep2 -Wl,--no-undefined

This should fail (to link) if foo.o or bar.o uses something not provided by libdep1 or libdep2 or libc.

Employed Russian