On Thursday 19 April 2001 1:01 am, Michael Matz wrote:
> 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
> [[snip]]
> 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.
How about this:
i) Track the addition of any `special_deplibs' in a separate variable
ii) Each time a new block is added from the $dependency_libs variable
in a dependent libtool pseudo-library, only do so like this:
case " $special_deplibs " in
*" $deplibs "*) ;;
*) deplibs="$deplibs $special_deplibs" ;;
esac
I think this will prevent repeated special deplib groups at least.
Comments?
This is definitely a post-1.4 fix IMHO, though we can always backport and
release 1.4.1 when we have a workable patch for post-MLB-merge-HEAD-branch.
However, I still think we might want to revert to the 2 year old relatively
complaint free (but marginally error-prone) duplicate removal for the release
of 1.4.
Cheers,
Gary.
--
___ _ ___ __ _ mailto: [EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
