bug-gnulib
[Top][All Lists]
Advanced

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

Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES


From: Ralf Wildenhues
Subject: Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html
Date: Wed, 11 Jan 2006 18:14:25 +0100
User-agent: Mutt/1.5.11

* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:44:27PM CET:
> Paul Eggert wrote:
> > I thought this module might be useful for people trying to build
> > executables on systems like Solaris where the "-lrt" option causes the
> > executable to dynamically link to rt, even if the executable does not
> > need any of the rt routines.
> 
> The problem is brought in by the fact that we build a single libgnulib or
> libcoreutils for all executables of a package, and if a single function
> in this library needs, say, high-resolution timers, the libgnulib or
> libcoreutils has "-lrt" in its link specification. Unfortunately, I know
> no better solution than yours.
> 
> > +       [gl_ldd_output0=`(ldd conftest$ac_exeext) 2>/dev/null` ||
> 
> This uses 'ldd'. This command is OS dependent:

Erm, yes.  Similarly, `-zignore' is linker dependent.  And if I know
anything about how autotools-using build systems expect link flags and
libraries, then you're not supposed to put `-lrt' in LDFLAGS, but in
LIBS.

Furthermore, the test looks completely bogus to me, testing a basically
empty program: how is that going to *reliably* record the need of librt
for a real program?

Am I missing something when suggesting AC_SEARCH_LIBS?  I see that the
point of this module may be that several users of a single libgnulib
exist, and only some may *need* `-lrt'.  Right?  Well, why doesn't
gnulib allow to separate LDADD per module then, as a refinement?
Something like:
  module foo needs LIBS=... LDFLAGS=..
  ..
  module bar needs module foo

Topological sort solves the ordering problem.  And yes, please make it
so that you don't break static linking as done with lib-link.


If instead you admit defeat, then:
- without libtool, you could go through the resulting link line and
  eliminate libraries one by one (given that *the order was good*),
  as done for example in the VIM source.  Slow, but at least reliable.
- with libtool, you're out of luck without severe hacks
  (i.e., file a bug report requesting an enhancement, please).

Cheers,
Ralf




reply via email to

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