Re: Duplicates in library auto-dependencies

[Gary V . Vaughan]

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: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc