Hi, On Mon, 5 Nov 2001, Rob Browning wrote:
> "Boehne, Robert" <[EMAIL PROTECTED]> writes: > > > This is a known problem that results from supporting multiple > > dependent archive libraries. In some cases libtool can't strip the > > redundant -lfoo -lbar in dependencies. > > Is this because it doesn't know how, or because stripping them would > be bad in some situations (what you say later implies the latter, but > I wanted to be sure), and if stripping duplicates would be bad, why? It's like this: static libraries may depend circularly on each other (shared libs too, but for those it doesn't matter), so there are situations, where -la -lb -la is required, and the second -la may not be stripped. libtool recognizes these situations, when the user gives _explicitely_ to the libtool link command such multiple -l arguments. libtool then also adds the appropriate -l flags to the dependency_libs in the .la file. If now that .la file is used for linking another lib, those multiple -l's are read in, and remembered. If the user now unfortunately gives one of those multiple -l's again also on libtools command line, it's added again, and no multiples are removed. Due to some bugs in libtool these double -l's might multiplicate more and more, even to non-sense situations like "-la -la -la -la -la -lb -la", but due to the "specialness" of -la they get not cleaned up. The point is (unless one fixes the assorted bugs in libtool), to be painfully sure, that one adds _nowhere_ the same -l argument multiple times to the same libtool link command (it's OK to repeat a dependence lib again, which might already be written in some .la file, which is used, i.e. suppose b.la contains already a -la, and one producues c.la by "libtool --mode=link ld -o c.la b.la -la". In that situation the multiple -la's _are_ removed. Compare this to "libtool --mode=link ld -o c.la b.la -la -la". From that command on all is doomed. All libraries depending on c.la will contain heaps over heaps of -la, which grow bigger and bigger the more far away c.la becomes in the dependecy list (e.g. if z.la dependes not directly on c.la, but only through y.la <-- x.la <-- w.la and so on, the list of -la's will probably span the equator). This is also how I handle it in KDE. Ensuring that no -l get into link commands multiple times (currently some plugins get multiple -l's, but that's no big problem, as they are not linked against, but are leaves in the dependecy tree). Note that the above workaround is based on a changed multiple-language-branch of libtool. I have no real experience with HEAD. It uses autoconf 2.5x exclusively, that's why I can't switch to it in KDE. Ciao, Michael. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
