Re: Motivation for -rpath-link

[Vladimir Prus <ghost at cs dot msu dot su>]

Hi Nick,

> > I'm somewhat confused about one sentence in -rpath-link documentaion. It
> > says:
> >
> >    When using ELF or SunOS, one shared library may require another.
> >     [....]
> >     When the linker encounters such a dependency when doing a non-shared,
> >     non-relocatable link, it will automatically try to locate the
> > required shared library and include it in the link, if it is not included
> > explicitly.
> >
> > Why this behaviour is desired?
>
> The behaviour is desired because the executable that is being created
> is supposed to be able to run without requiring *any* shared
> libraries.  ie it is completely self-contained.

Thanks for the explanation! However, I still don't understand something. Is
"non-shared non-relocatable link" the same as linking of an excutable, as 
opposed to .so?

> > For example, I have exe "main" which links to shared library "b",
> > which links to shared library "a".
>
> So the linker see that "main" requires symbols/code from shared
> library "b" and so it pulls the code from that shared library into the
> executable that it is creating.  Then is see that this code requires
> code from shared library "a", so it pulls in that code as well.  In
> the end you have an executable which can run even if the shared
> libraries "a" and "b" are not present in the run-time environment.

In my case, the excutable is regular dynamically linked one, so grabbing of 
transitive dependecies is not required. However, ld still tries to do that, 
and produces the following warning:

/usr/bin/ld: warning: a.so, needed by b/bin/gcc/debug/b.so, not found (try 
using -rpath or -rpath-link)

Of course, after I copy executable and all libraries to one location, all 
dynamic libraries are found -- so I don't understand why 'a.so' is included 
in link, and what the warning tries to tell me. 

- Volodya