Re: Patch to update libtool in GCC and Src trees

[libtool at cwilson dot fastmail dot fm]

On Fri, 11 May 2007 23:46:44 +0200, "Paolo Bonzini"
 
> 1) First possibility is to first copy newlib's libtool.m4 onto src/gcc, 
> and apply Chuck's suggested changes, at the same time.

I'd really advise against this [1].  I thought the goal (policy?) was
for the src and gcc trees to use only:
 (1) official released versions of external tools/libraries
 (2) or imported snapshots of said external tools/libraries taken
 directly from those external project's development tree
and that (gcc-, src-)local changes to the imported copies of those
external tools was verboten. Otherwise, we end up with
libtool-1.4.3-fork with five years worth of local changes.  That's bad.

If <some> change in newlib's libtool.m4 is desirable (and in this
particular case it seems moot), then send the patch to the libtool
folks, and once adopted into their tree, re-import.  However....

[1]
looking at the newlib cvs, newlib's version was first imported in July
2002 and has been modified only once since then (a one-line change, as
Steve has already described).  But newlib's version is 30k while
contemporaneous copies of libtool.m4 from libtool's cvs, branch-1.4 and
HEAD at that date were over 100k.  It looks like the version Fitzsimmons
originally imported was *not* a clean "take it directly from some
libtool release" import.

I'm not sure exactly *what* he did -- and there is no relevant message
from him on the newlib mailing list from that time period:
http://sourceware.org/ml/newlib/2002/authors.html
but that version does not seem to be "libtool's" libtool.m4 from any
branch.

So we *definitely* don't want to clobber Steve's new libtool.m4 (which,
along with the other libtool-related m4 files and ltmain.sh, was taken
directly from libtool HEAD as of 2007-03-18) with some random, hacked-up
version that's been sitting mostly untouched in newlib for five years
and only vaguely resembles *any* official libtool version from *any*
time in history.

> 2) Otherwise, we just update libtool in GCC and src trees, again 
> including Chuck's suggested changes in the patch.

The downside here, of course, is that the new libtool files are quite
different from what newlib uses on linux native today.  However, last
time I checked (about two weeks ago), libtool HEAD "just worked" on
linux -- passed all of libtool's own "old" testsuite, and all of
libtool's brand new dejagnu-based torture tests.  So I _really_ don't
expect any problems, using Steve's libtool, on a *native linux* target!

--
Chuck