Re: speed up large library linking

[Ralf Wildenhues]

Hi Peter,

* Peter O'Gorman wrote on Wed, May 11, 2005 at 04:33:52PM CEST:
> Ralf Wildenhues wrote:
> | First off: My laptop was broke last week, then some of our department's
> | hardware was destroyed, so: no mail reading, thus no patch checks, no
> | 1.5.18 release.
> 
> Do you need someone else to make the release? Sorry to hear about your
> hardware troubles.

Dunno.  Luckily the laptop turned out to be easy to fix, but mail
connection will be rocky for a while.  I believe I can do a release over
the holidays this weekend, though.  My only fear would be to miss mails
to bug-libtool meanwhile.

> | Immediate consequence for the libjava folks: Use of -objectlist is to be
> | preferred, with their (ancient!) libtool as well as with HEAD after the
> | changes below.  I have another optimization idea for -objectlist which
> | will kill some of the 2.8s left, but it needs more work, and might not
> | be immediately necessary.
> 
> Use of -objectlist with libjava is required, I haven't built libjava in a
> little while, I thought they used it, if not they are undoubtedly exceeding
> the kernel limit on command line lenght on some systems.

They use it for libgcj.la (where it is completely unnecessary :) but not
for libgcj0_convenience.la (where I believe it is necessary, but I am
certain it is helpful :).

While we are at it: Do we need to copy results (or pointers) to their
mailing list(s)?  Do their people that read here communicate this over?
Note I don't really read GCC lists except when I have suspected bugs to
report there.

> | My patches break one assumption held in libtool so far:  that --dry-run
> | will cause no file changes.
> 
> I understand your reasons for breaking this, but it freaks me out a little
> bit.

Why?

Note that the rename algorithm was not just quadratic because of
variable appending (it might've even been cubic or so, I did not bother
to check), but also because of the way it tested for doubled names.
I could not come up with a way so nicely solve this without temp files.
If that calculation were omitted in dry mode, we could not create the
same command lines as without --dry-run.

> Have you reported the quadratic behavior to the bash maintainers?
> We need to file bugs with them about this too.

No, but I will do so.  It's not just bash, however, but virtually any
shell I could find.

> Note that some of your FIXMEs in the patches below are in my opinion
> not needed, if libtool got the argument list and -objectlist was not
> used then the kernel limit was not exceeded and $ECHO is fine.

Oh yes, you are right.  I started adding these mechanically to all
dependent variables instead of only the ones where the object list gets
expanded.  Will post an updated patch.  Thanks for noticing this BTW,
less work to do.  :)

> | OK to apply them all to HEAD?
> 
> I am loathe to say 'No', but I will ask that you not commit these to HEAD
> without explicit approval.

Sure.

> speedup-features2.diff OK
> speedup-fixme2.diff  OK (even thought these comments may not always be
> warranted a reminder about command line length can't hurt)

See above.  I'll redo.

> The others scare me, I don't like the tempfiles. If no other maintainer
> approves in a few days I will look more closely.

Thanks for your response and this offer!

Cheers,
Ralf