Re: Patch to update libtool in GCC and Src trees

[Charles Wilson <libtool at cwilson dot fastmail dot fm>]

Paolo Bonzini wrote:
> > Attached are the various changelogs for GCC and the src tree, the one 
> > diff for src-release, and then an attachment with the ToT libtool that 
> > I have been using for testing.
>
> What was the status of AIX testing?  If that and Cygwin (possibly 
> including winsup/newlib -- CCing Charles Wilson) are ok, the patch can 
> go in as far as I'm concerned.  Sorry if I'm being extra safe, but the 
> hardest to maintain parts are in now.

---- winsup/newlib, cygwin -----

Well, I just did a native build of a winsup/newlib tree (that is, module 
winsup checkout from src CVS repository) with Steve's ToT libtool 
changes applied at the toplevel.  I had no significant issues (well, two 
problems, but they were unrelated and quickly fixed, and the cognizant 
persons notified).

Which is unsurprising, because winsup itself doesn't use libtool; and 
newlib in /this/ configuration is also built sans libtool.

However: on other platforms (see src/newlib/configure.host: at present, 
only linux native) newlib may in fact use libtool.  It doesn't appear 
that any of Steve's patches address that:

  (1) src/newlib/configure.in says "AC_CONFIG_AUX_DIR(..)" so
      newlib will see the "new" ltmain.sh
  (2) src/newlib/Makefile.am says "ACLOCAL_AMFLAGS = -I ." so
      aclocal will use newlib/libtool.m4, which is "old", and NOT
      the "new" src/libtool.m4 and the other .m4 friends.

Unless copies of the new libtool.m4&friends are placed in the
newlib directory, or ACLOCAL_AMFLAGS is modified to search .. first, 
this is bound to cause problems (version skew in ../ltmain.sh vs. 
./libtool.m4) for some people -- even if I didn't experience any 
problems on cygwin.

It'd be nice to say "sure, go ahead and commit, and we'll take care of 
newlib-on-linux-native later".  But I think if we do that, we will 
actually break newlib-on-linux-native, which is bad.  So, there are two 
choices:

(1) change newlib's AC_CONFIG_AUX_DIR to '.' and copy everything it 
might need from src/. into src/newlib/. -- which would include the old 
ltmain.sh, ltconfig, and lt-*.sh files, and regenerate all affected 
files.  That is, postpone the newlib switchover to the new libtool.

(2) remove newlib/libtool.m4, change newlib/Makefile.am's 
ACLOCAL_AMFLAGS to '-I .. -I .', regenerate all affected files.  That 
is, switch newlib over to the new libtool now.

Either way, Steve's existing patch needs to be extended to do 
_something_ with newlib, and that means a few more days of shakedown so 
the linux-native-newlib guys can test it.



---- gcc, NON-combined tree, cygwin -----

I last bootstrapped gcc on cygwin with Steve's ToT libtool changes about 
a week ago, and had no issues then. I don't see where anything in the 
last week would have changed that.



---- question about external tools -----

Ralf W. and I have been working on some refinements for cygwin/mingw 
libtool in libtool's ToT over the last few weeks.  They are not yet 
ready, and I certainly do not want to hold back gcc progress waiting on 
libtool: the 20070318 libtool ToT included in Steve's update works fine 
as demonstrated above.  However, now that Steve's done all or most of 
the _hard_ work, what will be the policy going forward with regards to 
updating external, but embedded, tools like libtool?

How often will gcc re-import the latest libtool ToT?  Any chance of 
another -- less disruptive! -- update before 4.THREE.0 ships?

--
Chuck