This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to update libtool in GCC and Src trees


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]