* 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 _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
