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

[Ralf Wildenhues]

* Paul Eggert wrote on Wed, Jan 11, 2006 at 07:28:55PM CET:
> Ralf Wildenhues <address@hidden> writes:
> 
> >  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.
> 
> Yes, that's what the lib-ignore code does; it puts -lm into LIBS in
> order to test -zignore.

Argh.  I misread the code, and badly at that.  Please take my humble
apologies, some of my resulting conclusions in my previous message were
completely nonsensical.

> > 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?
> 
> It works reliably on Solaris, for -lm.  It also works on Debian
> GNU/Linux, in that it discovers that -zignore isn't needed there.  If
> it breaks on some other platform then I'd like to know about it, and
> I'd like to fix it.

OK.  I don't know of any at the moment.

On the contrary, I'd see some usefulness for a similar macro in libtool.

Since classically I'd propose that a macro that would be useful for
different packages belong into Autoconf, but it has become style to put
stuff in gnulib instead, and never release that, I'm asking myself ATM
if that is just another sign of too few Autoconf releases.  Oh well.

> > why doesn't gnulib allow to separate LDADD per module then, as a
> > refinement?
> 
> gnulib already does that, with variables like LIB_CLOCK_GETTIME.  But
> the problem is maintaining the list of LDADDs.  At the end of this
> message is an extract from coreutils/src/Makefile.am.  This list is
> maintained by hand, and it's error-prone.

I agree.  The trade-off then is: ignore the too-many unused libs on
systems with lesser capable/unsupported linkers, against error-prone
maintenance-intensive makefiles.

Note that use of this macro won't save you from using AC_SEARCH_LIBS.

Cheers,
Ralf