Re: Patch to update libtool in GCC and Src trees

Charles Wilson
2007-05-08T03:47:07Z

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