Markus Trippelsdorf <mar...@trippelsdorf.de> writes: > By popular demand, I've prepared a patch that updates the in-tree > libtool to version 2.4.2. It is needed for lto-bootstrap with > -fno-fat-lto-objects and FreeBSD10.x versions. > It's a pretty big update as you can see by the following diffstat. I > cannot attach the patch even as a gzip file, because of its size: > > 417745 Oct 28 00:47 0001-update-to-libtool-2.4.2-and-regenerate.patch.gz > > Bootstrapped on x86_64-pc-linux-gnu. > > Comments? Stage 1 will end soon and it would be nice to get this in.
I've tried your patch on i386-pc-solaris2.11 this weekend in a variety of configurations: * using ld or gld 2.21.1, * with the 32-bit default configuration (i386-pc-solaris2.11) and the 64-bit default configuration (amd64-pc-solaris2.11). This revealed a couple of problems: * If Go support is included (off by default), bootstrap breaks like this while building libgo: libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.2.7a. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[4]: *** [go-assert.lo] Error 63 To avoid this, I've run all bootstraps without Go. * When building the 64-bit default gld configuration, building the 64-bit libjava fails like this: Error libtool: compile: not configured to build any kind of library libtool: compile: See the libtool documentation for more information. make[5]: libtool: compile: Fatal configuration error. I had already patched the copy of libtool.m4 to deal with the new configuration and now also submitted it upstream: Support 64-bit default GCC on Solaris/x86 http://lists.gnu.org/archive/html/libtool-patches/2011-10/msg00021.html After applying the patch and regenerating all affected configure scripts, the bootstrap completed. With those two changes, all four bootstraps completed without regressions. I made a quick comparison of the libtool.m4 in libgo/config with the 2.4.2 version: the only relevant change seems to be an instance of AC_PROG_GO, which also lives in go.m4. Ian will know why that additional copy is necessary. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University