Motivation for -rpath-link

[Ian Lance Taylor]

"Kai Ruottu" <karuottu@mbnet.fi> writes:

>  For instance with the 'sparc-solaris2.7' target the libraries in the 'sparcv9' subdir
> are not found although the '-m64' inserts those '-L' options into the linker command
> line, ie. the linker doesn't use them in any way what becomes to the stuff seen as
> 'NEEDED' in an 'objdump -p' output... The libs listed explicitly on the link command
> are of course found because of the used '-L' options, but not the libs told inside
> the explicitly listed libraries.
> 
>  So my question is: Is it a 'bug' or a 'feature' that those "NEEDED" libs for the
> multilibs are not found automagically but a '-rpath-link' will still be required for
> them?

The -L directories are not used for the -rpath or -rpath-link
directories.

The SunOS linker used -L for -rpath.  This historically led to a
number of problems, which is why it was dropped for Solaris.

The question then is whether -L should be used as a default for
-rpath-link.  I've generally felt that it is clearer not to confuse
the two concepts.  -L describes the linker search path.  -rpath
describes the dynamic linker search path.  Those two must be kept
separate.  -rpath-link describes the search path the linker should use
when it is emulating the dynamic linker search path.  It's easy to
come up with cases where -rpath-link and -L must be distinct.  On the
other hand, one could argue that -rpath-link should default to -L when
-rpath-link is not used.

I suspect that this issue will be somewhat less important with the
addition of the --unresolved-symbols option.

Ian