A.so is provided by a third party
B.so depends on A.so, but in
the makefile, B.so is not linked to A.so (not dynamically nor
statically).
C is a test executable for the B library. In the
makefile, C is dynamically linked to B and A.
ldd B.so
ldd C
make B compiles and builds B fine.
make C compiles and builds B and C fine.
./C runs with no issues (which surprises me)
the question:
- Can C pass down the location of A.so at run time to B when it needs it?
- Does B.so really need to link against A.so or it is ok if one of the dependents resolves that for it during link time.
- If so does the order of the dependencies resolved at C can cause issues for B.so. For example, if C resolves B.so before A.so B would fail. but if it resolves A.so first then B.so finds what it needs. Or the order of loading known which is exactly what is displayed in the output of ldd command
Can C pass down the location of A.so at run time to B when it needs it?
It's not clear what you mean by that.
C is already arranging for A.so to be loaded (by virtue of linking to A.so). What else do you want to "pass down"?
- Does B.so really need to link against A.so or it is ok if one of the dependents resolves that for it during link time.
It doesn't have to (as you've observed). But not linking B.so against A.so is error-prone, and in general is considered a bad practice.
For example, if C resolves B.so before A.so B would fail.
Again it's unclear what you mean by "resolves B.so before A.so".
When your binary C directly links against A.so and B.so in whatever order, both A.so and B.so are loaded by the dynamic linker before the first instruction of C executes.
The order only matters if A.so and B.so define conflicting symbols. In that case, the first library to define that symbol "wins" (its symbol is used).
Or the order of loading known which is exactly what is displayed in the output of ldd command
Yes, the order of loading is predefined by the way you link everything, and is exactly what ldd command prints.