[Top][All Lists]
[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
- new module lib-ignore; new section build_lib in MODULES.html, Paul Eggert, 2006/01/09
- Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html, Bruno Haible, 2006/01/11
- Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html,
Ralf Wildenhues <=
- Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html, Paul Eggert, 2006/01/11
- Re: [bug-gnulib] Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html, Bruno Haible, 2006/01/12
- Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html, Ralf Wildenhues, 2006/01/13
- Re: new module lib-ignore; new section build_lib in MODULES.html, Paul Eggert, 2006/01/18
- Re: new module lib-ignore; new section build_lib in MODULES.html, Ralf Wildenhues, 2006/01/18
- Re: new module lib-ignore; new section build_lib in MODULES.html, Bruno Haible, 2006/01/18