This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Motivation for -rpath-link
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: kai_ruottu at mbnet dot fi
- Cc: binutils at sources dot redhat dot com
- Date: 05 Nov 2003 09:07:20 -0500
- Subject: Re: Motivation for -rpath-link
- References: <3FA8F2F2.736.80CF42@localhost>
"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