I'm linking an executable that links against a .so.  The .so has a function in it that's in another .so.

The link for the original executable chokes at this point, saying that it can't find the secondary .so, needed by the 
primary one, needed by the executable.

It then immediately chokes, saying "undefined reference to xxx", where xxx is the function in the secondary .so, needed 
by the primary .so, needed by the executable.  (This function is not, by the way, needed by the executable, just by the 
.so it needs.)

I tried adding -rpath-link to it, and put the full path from C root all the way to the secondary .so's folder (being 
careful to swap \ for / .)

I still get the exact same error, including not being able to find the secondary .so.

Objdump shows the primary .so knows it needs the secondary .so, but (does not know where to look at runtime???  How 
would I check that?  I use -x for objdump and see the "NEEDED" line for it, no runtime path info, so I assumed it was 
just in the shared library path.)  Or is it embedded, and I need a different objdump argument to add or to look in a 
different part of the output of objdump?  Is this runtime path, if it exists, where the linker is trying to find the 
secondary .so, so it ignores rpath-link?

So:

1. Does -rpath-link not apply to "downstream" .so's?  What would I use in its place?

Assume for the sake of argument the (linktime path on the development machine) is not the same as the runtime path on 
the target device, which it is not.

The linker must find the .so at link time to verify the function it needs is, in fact, inside the .so, right?  So why 
does it ignore -rpath-link=c:/(somePathWithoutSpaces)/mySoLibDir ?