Re: Duplicates in library auto-dependencies

[Michael Matz]

Hi,

On Wed, 18 Apr 2001, Robert Boehne wrote:

> I'm in a bad situation with the loss of complete and draconian
> duplicate removal in dependency tracking.  I've got 44 or so
> libraries that depend on each other, usually not in a loop ;P
> So by the time the 10th library is built, there are thousands
> of duplicate -lm -lc -lstdc++ -lgcc options with current MLB.

Just before commiting my last merge of KDE's libtool and MLB I noticed
this too ;-)  There seem to be currently also other problems (I didn't
analyze them yet) connected with duplicate removal e.g. This is one link
command producing an application:
/bin/sh ../../libtool --mode=link --tag=CXX g++ -o kded dummy.o
  ../../kio/libksycoca.la kded.la

(I remove all -R,-L,-O,-D,-W and other flags)
and this is, what libtool produces as link command:
g++ -o .libs/kded dummy.o ../../kio/.libs/libksycoca.so -lm
-L/usr/lib/gcc-lib/i486-suse-linux/2.95.2 -L/usr/i486-suse-linux/lib
-lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm
-lgcc -lc -lgcc -lm -lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm -lgcc -lc
-lgcc -lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm -lgcc -lc -lgcc -lstdc++
-lm -lgcc -lc -lgcc ./.libs/kded.so
/src/noo/kdelibs/kio/.libs/libksycoca.so
/src/noo/kdelibs/kio/.libs/libkio.so
/src/noo/kdelibs/kdeui/.libs/libkdeui.so -lm -lstdc++ -lm -lgcc -lc -lgcc
-lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm -lgcc -lc -lgcc
/src/noo/kdelibs/kdesu/.libs/libkdesu.so
/src/noo/kdelibs/kdecore/.libs/libkdecore.so
/src/noo/kdelibs/kdecore/.libs/libkdefakes.so -ldl
/src/noo/kdelibs/dcop/.libs/libDCOP.so -lqt -lpng -lm /usr/lib/libjpeg.so
-lXext -lX11 -lSM -lICE -lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm -lgcc
-lc -lgcc -lutil -lstdc++ -lm -lgcc -lc -lgcc -lz /usr/lib/libfam.so
-lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm -lgcc -lc -lgcc -lstdc++ -lm
-lgcc -lc -lgcc

Esp. note the doubled libksycoca.so (if I see right in the buildlog, for
each application the first deplib is doubled, but that's just a first
guess).  Anyway this is unacceptable, and if I'm not mistaken also
unnecessary.  The problem that Alexander was commiting the "mark
compiler-internal deplibs special" thing, was, that the duplicate removal
was removing one of the -lgcc.  But it would also be fixed, when the
duplicate-removal, and generally all the handling of $libs would not touch
the $postdeps at all.  This way "-lstdc++ -lm -lgcc -lc -lgcc" would
still be added to every link command.  Hmm, I guess I basically mean,
that $postdeps simply shouldn't be added blindly to $deps in the first
place, but instead should be checked additionally later, where
appropriate (e.g. for the link command, or the checking of sharedness)

I think, that one final "-lstdc++ -lm -lgcc -lc -lgcc" in the link command
is enough for every case, there is no (practical) situation, where other
instance of that string make sense, ergo there should not be many places
where the existance of those -lxxx's make any difference to libtool at
all, as long as they are added to the link-command and they are checked
with deplibs_check_method.


Ciao,
Michael.