libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: linking of indirect dependencies (dependency_libs) on Linux


From: Ralf Wildenhues
Subject: Re: linking of indirect dependencies (dependency_libs) on Linux
Date: Wed, 3 Aug 2005 09:54:44 +0200
User-agent: Mutt/1.4.1i

Hi Steve,

* Steve Langasek wrote on Wed, Aug 03, 2005 at 03:37:18AM CEST:
> On Tue, Aug 02, 2005 at 05:41:32PM +0200, Ralf Wildenhues wrote:
> >
> > 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.

OK, I believe one of the was this:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00050.html
and with this one (same software package) I actually don't remember if
that turned out to be Debian-specific (i.e., link_all_deplibs specific):
http://lists.gnu.org/archive/html/libtool/2005-01/msg00143.html

The one nicely exposed the problem of non-linked against libs (and
their rpaths) though.

Maybe the simple fix for this would be to link against all uninstalled
deplibs but not against the installed ones?  Man, these semantics are
going to be difficult to describe consistently in the manual..

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

Honestly, I could not tell you.  We are actually trying not to put any
new features in branch-1-5.  And getting branch-2-0 out the door has
been promised years ago already, so we're not really good at making
promises.  :)

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

Yes, I was kind of remembering Alexandre's comment from
http://lists.gnu.org/archive/html/libtool/2004-12/msg00259.html

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

Shoot.  I did not know that, thanks.

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

Ahh, good to know Debian people seem to think this, too.  I've read
about your policy of enabling it post-sarge, and have been a little
worried that it would turn up hideous bugs much later.

This comment actually pushes toward what the deplibs RFC discussion
kind of turned to, sounds good.

> 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 :-)

ACK.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]