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

[Stefan Muller]

Ralf,

Thanks for picking up the issue. I don't think it makes a lot of sense to simply prevent the -R flags from propagating on ALL systems arguing that the linker on SOME systems might not understand it, for two reasons:

(1) It breaks the linking of the final executables on systems that understand the -R flag (if the user wants to use -R to resolve secondary dependences of a library that the executables depend upon)

(2) On systems that don't understand -R, the problem would already appear when the user tries to use -R to link the library. So preventing -R from propagating never fixes anything.

I can't think of a scenario where one would want libtool to suppress the propagation of -R flags: Users who don't want to use -R wouldn't have used it to link their libraries in the first place, right?

Cheers,

Stefan

On Thu, Jan 7, 2010 at 12:06 PM, Ralf Wildenhues <address@hidden> wrote:

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