This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Patch to update libtool in GCC and Src trees
- From: Charles Wilson <libtool at cwilson dot fastmail dot fm>
- To: bonzini at gnu dot org
- Cc: Steve Ellcey <sje at cup dot hp dot com>, binutils at sourceware dot org, gcc-patches at gcc dot gnu dot org, gdb-patches at gcc dot gnu dot org, newlib at sourceware dot org
- Date: Mon, 07 May 2007 23:46:54 -0400
- Subject: Re: Patch to update libtool in GCC and Src trees
- References: <463F6F90.4080401@cup.hp.com> <463F873D.5000706@lu.unisi.ch>
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