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

[Ralf Wildenhues]

Hello,

* Todd Gamblin wrote on Wed, Jan 06, 2010 at 07:00:43PM CET:
> I first reported this issue on September 24, 2009.  I would post a
> link to the archive, but it looks like the archive is down
> (http://mail.gnu.org/mailman/listinfo/bug-libtool gives me 404 not
> found).  I've pasted my original email below, along with the initial
> response I got from Ralf.  I've been trying to get an answer on this
> since then, but Ralf hasn't responded to any of my followups.

No, because I haven't had the time to look into the issue.

The
  -R*) ;;

line has been added to ltmain for some reason, and merely removing it
would likely cause a regression for some system or setup.

I've looked a bit now.  It comes from
<http://lists.gnu.org/archive/html/libtool-patches/2003-03/msg00086.html>
which originates from
<http://lists.gnu.org/archive/html/bug-gnu-utils/2003-01/msg00009.html>.

The former states:

  This patch was posted on a GNU mailing list by Albert Chin. It is essential
  for use of libtool, libintl etc. on all platforms where the linker doesn't
  understand the -R flag directly, like OSF/1. The -R flags from a .la's
  dependency_libs are taken into account by a different variable and must be
  ignored in this particular pass.

That -R are taken into account elsewhere is probably only true for
$dependency_libs but not propagation.  However, it is likely true
that reverting the patch will break things for linkers don't understand
-R directly.

So the next step would be to extend libtool/tests/runpath-in-lalib.at,
so that it exposes the bug, then fix the bug, while ensuring that we
don't regress for linkers that do not understand -R.

Besides all that, I'm pretty sure that some people actually have come to
expect the current behavior, and will complain about the unconditional
propagation of -R flags.  I'm not yet sure what to do about that.

Cheers,
Ralf