Bruno Haible <[EMAIL PROTECTED]> writes: > linktool gcc -o cp cp.o ../lib/libcoreutils.a $(LDADD) > > The idea would be that it removes -l options from the command line as long > as the link continues to succeed. 'vim' links this way.
It would be nice to have something portable, but the naive algorithm you mentioned would be an O(N**2) algorithm, would it not? Or even worse if you wanted a minimal number of libraries. 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". (Admittedly this might be a bit slow.) > 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. In the case you describe, I'd expect the libbaz foo to be an undesirable interloper more often than not.
