Re: Bugreport: Incorrect forwarding of a shared library's -R flags when this library is linked to an executable

[Ralf Wildenhues]

* Todd Gamblin wrote on Thu, Jan 07, 2010 at 11:21:29PM CET:
> Why does libtool draw a distinction between -R and -rpath?  GNU ld
> treats -R plus directory name as a synonym for -rpath, so these are
> effectively the same once things get through libtool and down to the
> linker.  Or am I mistaken about this?

When creating a libtool library, libtool interprets -rpath very
differently from -R.  -rpath <libdir> means: the library will eventually
be installed in <libdir>.  It does *not* cause a run path to be added to
the library.  When creating a libtool library without passing -rpath,
libtool will only create a convenience archive, not to be installed.

This may seem confusing, when you come from the GNU ld semantics.
It is.  I can't tell you why this API was chosen this way, but it's
cast in stone and far too late to change this now.

When creating a program, -R and -rpath are synonymous.

> It seems like -rpath is understood by quite a few linkers, so why
> can't libtool just translate -R arguments to -rpath arguments on
> systems where -R isn't understood?

libtool does that.  It *just* didn't do it correctly for -R entries
picked up from deplibs' $dependency_libs entries.  I've tried to explain
that in my previous message, maybe it wasn't clear enough.

Cheers,
Ralf