Re: linking of indirect dependencies (dependency_libs) on Linux

[Steve Langasek]

On Tue, Aug 02, 2005 at 05:41:32PM +0200, Ralf Wildenhues wrote:
> * Steve Langasek wrote on Wed, Jul 27, 2005 at 02:01:35PM CEST:

> > Is there no one out there who can answer this question from my mail of last
> > week,

> I've been away, sorry for the late response.

Ok, no worries. :)

> > On Thu, Jul 21, 2005 at 03:07:35AM -0700, Steve Langasek wrote:
> > 
> > > Last March, Scott James Remnant put together a patch which fixed libtool 
> > > to
> > > not gratuitously add indirect library dependencies to the linker line when
> > > doing shared linking on Linux.  I was distraught to learn from him just
> > > yesterday that this patch was never actually accepted upstream.  We've 
> > > been
> > > using it to good effect for the past year in Debian, and I was fully under
> > > the impression that I could look forward to this change streamlining our
> > > Debian development processes as more and more software began to use it
> > > upstream, reducing the need to recompile software linked to libraries it
> > > shouldn't have been linked to.  Evidently, this is not the case.

> > > I can find only one very short thread
> > > <http://lists.gnu.org/archive/html/libtool-patches/2004-03/msg00111.html>
> > > about this patch in the libtool-patches archive, which doesn't appear to
> > > include much discussion.  Can someone explain to me what the rationale was
> > > for rejecting this patch, so that I can address those reasons?

> Well, I can at least point you to much much more discussion about the
> general issue.  Alas, other (libtool and non-libtool related) work has
> kept at least me from progressing in this regard.

> deplibs RFC discussion:
> http://lists.gnu.org/archive/html/libtool/2004-12/msg00029.html
> http://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html

Thank you (to you and Peter both) for providing these references to further
discussion; I wouldn't have thought to look that far forward in the archive
based on the outcome of what I'd found earlier. :)  It will take me a little
while in turn to go through these and get a handle on the issues, amid the
other stuff I have going on; but rest assured, I'll be back.

> There were also a couple of bug reports related to Debian having
> link_all_deplibs=no, but the user expecting otherwise.
> For example, if you want to use an uninstalled debugging version of a
> library, but the missing explicit link only gets you the installed one
> on runtime (I can search for the report if you're interested).

If you could point me to that report, that would be appreciated.  I think
the deplibs issue is an important one, and am happy to do some gruntwork to
get this patch into a shape that you would accept.

My personal hope is that this fix could be incorporated into a release of
libtool in time for GNOME upstream to use it for their 2.12 release in
October.  Is that a realistic goal?

On Tue, Aug 02, 2005 at 11:56:14PM +0200, Kurt Roeckx wrote:
> On Tue, Aug 02, 2005 at 05:41:32PM +0200, Ralf Wildenhues wrote:

> > Well, I can at least point you to much much more discussion about the
> > general issue.  Alas, other (libtool and non-libtool related) work has
> > kept at least me from progressing in this regard.  Also, the newer GNU
> > ld switches might want us rethinking this issue, maybe.

> Are you talking about the --as-needed switch?  I've heard this is
> causing problems in combination with libtool but don't know the
> details.  Maybe Steve knows more?

Yes, --as-needed is quite a new feature of binutils, and as of binutils 2.16
is broken on at least alpha/linux and sparc/linux.  Frankly, I also think
it's a kludge that only ever entered into consideration because of the
current behavior of libtool and pkg-config, and it only serves to put the
final binaries farther out of the control of the author/maintainer.  (There
are certainly real use cases where one *doesn't* want to trim libraries that
are specified explicitly on the linker commandline...)

Also, GNU/Linux is not the only platform that stands to benefit from this
(even though Scott's patch conservatively enabled it only on the platform
we were testing), nor is there any reason it should be specific to systems
using recent GNU binutils, so from the standpoint of the libtool design
philosophy I think this would still be the right thing to do :-)

Cheers,
-- 
Steve Langasek
postmodern programmer

signature.asc
Description: Digital signature