Luciano
Luciano

Reputation: 1601

Is there an automated way to figure out Shared Object Dependencies?

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.

Upvotes: 3

Views: 3520

Answers (2)

Employed Russian
Employed Russian

Reputation: 213526

"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.

Upvotes: 2

agl
agl

Reputation: 1662

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.

Upvotes: 1

Related Questions