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

[Todd Gamblin]

Ralf,

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

Thanks for taking a look at this.  I realize you're swamped -- so  
please don't think this was meant as a jab.  Obviously all of us  
appreciate the work you do on libtool.

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

I imagine a lot of people probably expect the current behavior, so  
maybe the practical thing to do short-term is to "fix" the  
documentation... the manual still claims that -R gets propagated, but  
it looks like that hasn't been the case since 2003.  That's not to say  
that I like the current behavior (I would like -R propagation) but I  
was surprised when this didn't work for me.

On Jan 7, 2010, at 1:14 PM, Ralf Wildenhues wrote:
> 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.

I think this is the right idea, especially with -R, as it can be kind  
of a controversial subject.

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

Isn't this the core of the issue?  -R propagation should be fully  
specifiable by whoever's building the program or library, and libtool  
shouldn't surprise people by inheriting that intent from some  
dependence.  I can imagine two people using the same system wanting  
different behaviors for this depending on how they have their  
environment set up and on how their system is administered.

Couldn't you solve this with another libtool option specifiable in,  
say, LDFLAGS?  Then people could decide for themselves whether they  
want this in their binaries.  You could keep the default as it is now  
but allow people like Stefan and myself to specify that we want  
indirect dependencies in the run path.

-Todd