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

[Ralf Wildenhues]

Hello Stefan,

please don't top-post; thanks.

* Stefan Muller wrote on Thu, Jan 07, 2010 at 09:52:36PM CET:
> 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 didn't mean to say that not propagating -R was the right thing; but
understanding first why some change was made in the past can help avoid
regressions.

In other uses of -R libtool does the right thing and translates it to
the linker-specific way of spelling "add this directory to the run
path".  The right fix to this bug is probably to ensure that this
happens here as well, for -R paths read from deplib's $dependency_libs.

> 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?

I can think of it.  Many users/distros don't like run paths embedded in
their programs or libraries.  In this case, a fix could cause a -R path
stemming from a third-party library (they never compiled themselves)
that they link to, to propagate to their compiled output.  That's not
much different from not wanting to link against indirect deplibs.

Cheers,
Ralf