Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
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
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
Rainer Orth r...@cebitec.uni-bielefeld.de writes: 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. The version of AC_PROG_GO in libgo/config/go.m4 is there so that I can rebuild libgo/configure with a version of autoconf that does not have Go support. The version of AC_PROG_GO in libgo/config/libtool.m4 is there because all the languages work that way in libtool.m4. Ian
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 2011.10.28 at 07:20 +0200, Markus Trippelsdorf wrote: On 2011.10.27 at 17:29 -0700, Andi Kleen wrote: 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. Can you put it up for download somewhere? Does the slim bootstrap now work on Linux? http://trippelsdorf.de/0001-update-to-libtool-2.4.2-and-regenerate.patch.bz2 I presume it needs at least the gcc-ar patch too, unless you use custom AR/RANLIB wrappers. Yes, slim bootstrap now works on Linux. One has to point AR, AR_FOR_TARGET, etc. to the wrappers and add -fuse-linker-plugin to the various CFLAGS (BOOT_CFLAGS, STAGE1_CFLAGS and CFLAGS_FOR_TARGET). Here is what I use right now: % cat config/slim-lto-bootstrap.mk # This option enables slim LTO for stage2 and stage3. STAGE2_CFLAGS += -flto=jobserver -fno-fat-lto-objects -frandom-seed=1 STAGE3_CFLAGS += -flto=jobserver -fno-fat-lto-objects -frandom-seed=1 STAGE_CFLAGS += -fuse-linker-plugin STAGEprofile_CFLAGS += -fno-lto AR=/usr/local/bin/ar NM=/usr/local/bin/nm RANLIB=/usr/local/bin/ranlib AR_FOR_TARGET=/usr/local/bin/ar NM_FOR_TARGET=/usr/local/bin/nm RANLIB_FOR_TARGET=/usr/local/bin/ranlib And the following patch to force fixincludes to honor CFLAGS: diff --git a/Makefile.in b/Makefile.in index d1206bd..3f3f9e0 100644 --- a/Makefile.in +++ b/Makefile.in @@ -2819,6 +2819,7 @@ configure-build-fixincludes: test ! -f $(BUILD_SUBDIR)/fixincludes/Makefile || exit 0; \ $(SHELL) $(srcdir)/mkinstalldirs $(BUILD_SUBDIR)/fixincludes ; \ $(BUILD_EXPORTS) \ + CFLAGS=$(STAGE_CFLAGS); export CFLAGS; \ echo Configuring in $(BUILD_SUBDIR)/fixincludes; \ cd $(BUILD_SUBDIR)/fixincludes || exit 1; \ case $(srcdir) in \ @@ -2854,6 +2855,7 @@ all-build-fixincludes: configure-build-fixincludes $(BUILD_EXPORTS) \ (cd $(BUILD_SUBDIR)/fixincludes \ $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_BUILD_FLAGS) \ + CFLAGS=$(STAGE_CFLAGS) \ $(TARGET-build-fixincludes)) @endif build-fixincludes @@ -7729,6 +7731,7 @@ configure-fixincludes: test ! -f $(HOST_SUBDIR)/fixincludes/Makefile || exit 0; \ $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/fixincludes ; \ $(HOST_EXPORTS) \ + CFLAGS=$(STAGE_CFLAGS); export CFLAGS; \ echo Configuring in $(HOST_SUBDIR)/fixincludes; \ cd $(HOST_SUBDIR)/fixincludes || exit 1; \ case $(srcdir) in \ @@ -7763,6 +7766,7 @@ all-fixincludes: configure-fixincludes $(HOST_EXPORTS) \ (cd $(HOST_SUBDIR)/fixincludes \ $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) \ + CFLAGS=$(STAGE_CFLAGS) \ $(TARGET-fixincludes)) @endif fixincludes With this in place you can configure and build gcc --with-build-config=slim-lto-bootstrap . I haven't figured out yet how to use gcc-ar et al. instead of the shell wrappers. The plugin path seems to be hardcoded, which is unfortunate. Would it be possible to make the wrappers more flexible, so that they could be used during bootstrap? -- Markus
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
I haven't figured out yet how to use gcc-ar et al. instead of the shell wrappers. The plugin path seems to be hardcoded, which is unfortunate. Would it be possible to make the wrappers more flexible, so that they could be used during bootstrap? The path can be set with GCC_EXEC_PREFIX currently. Maybe the makefile could set that. I considered implementing -B, but I was afraid it would conflict with some wrapped program option. Maybe there's a way around that. -Andi
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
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. I see that your patch doesn't deal with libgo/config, where a private copy of libtool is kept. Would it be possible to get rid of that, given that 2.4.2 does support Go? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
Rainer Orth r...@cebitec.uni-bielefeld.de writes: 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. I see that your patch doesn't deal with libgo/config, where a private copy of libtool is kept. Would it be possible to get rid of that, given that 2.4.2 does support Go? I hope so, but that can probably be a separate patch after the main one is in. Ian
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On Fri, 28 Oct 2011, Markus Trippelsdorf wrote: What about the issues with libtool's notion of sysroots, as mentioned in http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02037.html - have those been resolved, and if so, how? And what about the directories only present in the src repository that will also need updating for such a toplevel change? Oops, you're right, libtools with_sysroot still clashes with gcc's notion. But that should be easily fixable by just reverting one commit (3334f7ed5851ef1) in libtool. I'm afraid I don't understand your second question. Can you elaborate on that? Because of the shared toplevel build system, the gcc and src repositories need to have their configure scripts etc. regenerated at the same time for a change such as this (and it should be tested that binutils, newlib and the other directories in the src repository do still build properly after the regeneration). -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 2011.10.28 at 15:34 +, Joseph S. Myers wrote: On Fri, 28 Oct 2011, Markus Trippelsdorf wrote: What about the issues with libtool's notion of sysroots, as mentioned in http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02037.html - have those been resolved, and if so, how? And what about the directories only present in the src repository that will also need updating for such a toplevel change? Oops, you're right, libtools with_sysroot still clashes with gcc's notion. But that should be easily fixable by just reverting one commit (3334f7ed5851ef1) in libtool. I'm afraid I don't understand your second question. Can you elaborate on that? Because of the shared toplevel build system, the gcc and src repositories need to have their configure scripts etc. regenerated at the same time for a change such as this (and it should be tested that binutils, newlib and the other directories in the src repository do still build properly after the regeneration). OK. Although it appears that it was handled in a cascaded fashion the last time: Last gcc update was on : 2009-12-05 Last binutils update : 2010-01-09 -- Markus
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 28.10.11 01:35, Markus Trippelsdorf wrote: 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. For the record: http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03138.html Thanks!!! Andreas
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 10/28/2011 10:33 AM, Rainer Orth wrote: 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. I see that your patch doesn't deal with libgo/config, where a private copy of libtool is kept. Would it be possible to get rid of that, given that 2.4.2 does support Go? same for libjava/libltdl
[RFC PATCH] update to libtool-2.4.2 and regenerate
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. boehm-gc/Makefile.in |3 + boehm-gc/configure | 1901 ++-- boehm-gc/include/Makefile.in |3 + boehm-gc/include/gc_config.h.in|6 - boehm-gc/testsuite/Makefile.in |3 + fixincludes/configure | 99 +- gcc/configure | 1422 +-- intl/config.h.in | 232 +- intl/configure | 4764 +++- libffi/Makefile.in |3 + libffi/configure | 1474 +-- libffi/include/Makefile.in |3 + libffi/man/Makefile.in |3 + libffi/testsuite/Makefile.in |3 + libgfortran/Makefile.in|3 + libgfortran/configure | 1940 ++--- libgomp/Makefile.in|3 + libgomp/configure | 1928 ++--- libgomp/testsuite/Makefile.in |3 + libjava/Makefile.in|2 + libjava/classpath/Makefile.in |3 + libjava/classpath/configure| 1911 ++--- libjava/classpath/doc/Makefile.in |3 + libjava/classpath/doc/api/Makefile.in |3 + libjava/classpath/examples/Makefile.in |3 + libjava/classpath/external/Makefile.in |3 + libjava/classpath/external/jsr166/Makefile.in |3 + .../classpath/external/relaxngDatatype/Makefile.in |3 + libjava/classpath/external/sax/Makefile.in |3 + libjava/classpath/external/w3c_dom/Makefile.in |3 + libjava/classpath/include/Makefile.in |3 + libjava/classpath/lib/Makefile.in |3 + libjava/classpath/native/Makefile.in |3 + libjava/classpath/native/fdlibm/Makefile.in|3 + libjava/classpath/native/jawt/Makefile.in |3 + libjava/classpath/native/jni/Makefile.in |3 + libjava/classpath/native/jni/classpath/Makefile.in |3 + .../classpath/native/jni/gconf-peer/Makefile.in|3 + .../native/jni/gstreamer-peer/Makefile.in |3 + libjava/classpath/native/jni/gtk-peer/Makefile.in |3 + libjava/classpath/native/jni/java-io/Makefile.in |3 + libjava/classpath/native/jni/java-lang/Makefile.in |3 + libjava/classpath/native/jni/java-math/Makefile.in |3 + libjava/classpath/native/jni/java-net/Makefile.in |3 + libjava/classpath/native/jni/java-nio/Makefile.in |3 + libjava/classpath/native/jni/java-util/Makefile.in |3 + libjava/classpath/native/jni/midi-alsa/Makefile.in |3 + libjava/classpath/native/jni/midi-dssi/Makefile.in |3 + .../classpath/native/jni/native-lib/Makefile.in|3 + libjava/classpath/native/jni/qt-peer/Makefile.in |3 + libjava/classpath/native/jni/xmlj/Makefile.in |3 + libjava/classpath/native/plugin/Makefile.in|3 + libjava/classpath/resource/Makefile.in |3 + libjava/classpath/scripts/Makefile.in |3 + libjava/classpath/tools/Makefile.in|3 + libjava/configure | 2206 +++--- libjava/gcj/Makefile.in|4 +- libjava/include/Makefile.in|4 +- libjava/testsuite/Makefile.in |4 +- libmudflap/Makefile.in |3 + libmudflap/configure | 1474 +-- libmudflap/testsuite/Makefile.in |3 + libobjc/configure | 1501 +-- libquadmath/Makefile.in|3 + libquadmath/configure | 1474 +-- libssp/Makefile.in |3 + libssp/configure | 1474 +-- libstdc++-v3/Makefile.in |3 + libstdc++-v3/configure | 1917 ++--- libstdc++-v3/doc/Makefile.in |3 + libstdc++-v3/include/Makefile.in |3 + libstdc++-v3/libsupc++/Makefile.in |3 +
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
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. Can you put it up for download somewhere? Does the slim bootstrap now work on Linux? I presume it needs at least the gcc-ar patch too, unless you use custom AR/RANLIB wrappers. The last time I tried slim bootstrap a long time ago I also ran into some problems with the libcpp Makefiles. But I agree it would be good to have for 4.7: it would be good if the compiler could be actually bootstrapped with slim LTO, and then a slim-lto-bootstrap config could be added. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On Fri, 28 Oct 2011, Markus Trippelsdorf wrote: 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. What about the issues with libtool's notion of sysroots, as mentioned in http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02037.html - have those been resolved, and if so, how? And what about the directories only present in the src repository that will also need updating for such a toplevel change? -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 2011.10.27 at 17:29 -0700, Andi Kleen wrote: 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. Can you put it up for download somewhere? Does the slim bootstrap now work on Linux? http://trippelsdorf.de/0001-update-to-libtool-2.4.2-and-regenerate.patch.bz2 I presume it needs at least the gcc-ar patch too, unless you use custom AR/RANLIB wrappers. Yes, slim bootstrap now works on Linux. One has to point AR, AR_FOR_TARGET, etc. to the wrappers and add -fuse-linker-plugin to the various CFLAGS (BOOT_CFLAGS, STAGE1_CFLAGS and CFLAGS_FOR_TARGET). The last time I tried slim bootstrap a long time ago I also ran into some problems with the libcpp Makefiles. I've seen no problems thus far in my testing. -- Markus
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 2011.10.28 at 00:41 +, Joseph S. Myers wrote: On Fri, 28 Oct 2011, Markus Trippelsdorf wrote: 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. What about the issues with libtool's notion of sysroots, as mentioned in http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02037.html - have those been resolved, and if so, how? And what about the directories only present in the src repository that will also need updating for such a toplevel change? Oops, you're right, libtools with_sysroot still clashes with gcc's notion. But that should be easily fixable by just reverting one commit (3334f7ed5851ef1) in libtool. I'm afraid I don't understand your second question. Can you elaborate on that? And BTW my patch was just meant to get the ball rolling, not necessary as the final solution. -- Markus
