* Paul Eggert wrote on Mon, Jun 19, 2006 at 09:35:43AM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> 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
