bug-gnulib
[Top][All Lists]
Advanced

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

Re: [bug-gnulib] gettext: -lintl if necessary


From: Ralf Wildenhues
Subject: Re: [bug-gnulib] gettext: -lintl if necessary
Date: Mon, 19 Jun 2006 10:14:44 +0200
User-agent: Mutt/1.5.11

* Paul Eggert wrote on Mon, Jun 19, 2006 at 09:35:43AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> > One problem with generally using this is that libtool will track the
> > library dependencies regardless of whether the library is actually
> > needed or not -- it cannot know.
> 
> 'cannot' is a bit too strong, surely.  It could "know", using the same
> sort of method that binutils ld --as-needed or Sun ld -z ignore "knows".

But there are legitimate uses out there that break when --as-needed is
added.  Some packages link the main program or shared libraries against
third party libraries just so modules later dlopen'ed find the necessary
symbols.  Yes, I know it's not portable (or The Right Thing[tm]) to do
so, but not every package is written to be portable, --as-needed breaks
this usage case; and it can not know.

> (Admittedly this might be a bit slow.)

What an understatement...  ;-)

> > I think (and I'm clearly waving my hands here), you
> > could have the problem that if
> >
> > - you have a program that needs symbol foo from libfoo,
> > - but a dependency libbar listed in one of the dependencies of the
> >   installed libbaz (which itself depends on gnulib code) also provides
> >   a symbol foo,
> 
> I don't entirely follow the example, but I expect that such cases are
> more likely to work with --as-needed than without, at least for
> programs like coreutils that don't invoke the dynamic linker.

Yes.  I am certainly not arguing the coreutils case; this thread started
off with the suggestion to have gnulib use this module.  I don't dispute
either that the module should be put into gnulib.  However, I'd like to
avoid that gnulib ends up just dumping all needed libraries into one
variable, forcing gnulib users to bite and link against them all or use
$as_needed (whatever it's called): the choice whether it's useful or not
should clearly be put to the package in question, not dictated by the
gnulib modules.

> In the case you describe, I'd expect the libbaz foo to be an
> undesirable interloper more often than not.

Symbol interposition may be exploited to provide, say, a debugging
version of malloc, or a CPU-optimized version of dgemm, or a non-stub
version of pthread_*.

If --as-needed would globally be the right answer, there wouldn't be bug
reports against Libtool to support it for only a subset of the libraries
on the command line.  (Libtool currently doesn't support this.)
See these threads
http://mail-index.netbsd.org/tech-toolchain/2005/05/06/0001.html
http://archives.postgresql.org/pgsql-hackers/2005-05/msg00488.php
for other uses or systems where as-needed semantics aren't always
desirable.

BTW, are the bugs wrt. as-needed fixed on all systems now?  I recall it
was broken on some lesser-used hosts for a while (sorry, can't find a
good URL right now).

Cheers,
Ralf




reply via email to

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