two more build results for gcc 4.3.2
I located a couple of old machines to try, so I have two more successful build reports, and one failure (though don't worry about the failure yet). First one (includes C, C++, ObjC, Fortran, and Java) i686-pc-linux-gnu on a RHEL 3 system. boot compiler: gcc 3.3.6 (FSF release) kernel: 2.4.21-32.EL (from Red Hat) glibc: 2.3.2-95.33 (from Red Hat) binutils: 2.17 (FSF release) GMP: 4.1.2-5 (from Red Hat) MPFR: 2.3.1 Results: http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00304.html The failures and noise are evidently due to the ancient glibc. Second one (includes C, C++, ObjC, and Fortran) hppa2.0w-hp-hpux11.00 This is an HP 9000/800/L1000-36 Bootstrapped with gcc 3.2.3. as is from binutils-2.18 (FSF), native linker gmp is 4.2.2 (FSF) mpfr is 2.3.1 (FSF) Results: http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00306.html No issues building GCC, I did have to turn off -Werror in a couple of places to get binutils 2.18 to build with gcc. I also found an ia64 box running Red Hat Advanced Workstation 2.1. Yes, I know, really old, but I can't change it. I tried a build using Bootstrap compiler is FSF gcc 3.2.3 kernel: kernel-2.4.18-e.12smp (from Red Hat) glibc: 2.2.4-29.2 (from Red Hat) binutils: 2.18 (FSF) gmp: 4.2.2 (FSF) mpfr: 2.3.1 (FSF) but the bootstrap died. gcc itself three-stage bootstrapped OK, then died during the multilib configuration for libgcc. It might just have been an issue with the shared library path, now that I look at it; I'll re-check.
Re: two more build results for gcc 4.3.2
On Thu, Sep 04, 2008 at 11:12:59AM -0700, Joe Buck wrote: I also found an ia64 box running Red Hat Advanced Workstation 2.1. Yes, I know, really old, but I can't change it. I tried a build... but the bootstrap died. I think the issue was that the --with-gmp and --with-mpfr directories weren't in LD_LIBRARY_PATH. I'm re-trying. If that's the issue, I think that it should automatically be taken care of; the configure process can determine that it's picking up shared libraries that aren't on the default path and make sure that things work anyway.
Re: two more build results for gcc 4.3.2
On Thu, Sep 04, 2008 at 11:12:59AM -0700, Joe Buck wrote: I also found an ia64 box running Red Hat Advanced Workstation 2.1. Yes, I know, really old, but I can't change it. I tried a build... but the bootstrap died. On Thu, Sep 04, 2008 at 11:37:47AM -0700, Joe Buck wrote: I think the issue was that the --with-gmp and --with-mpfr directories weren't in LD_LIBRARY_PATH. I'm re-trying. If that's the issue, I think that it should automatically be taken care of; the configure process can determine that it's picking up shared libraries that aren't on the default path and make sure that things work anyway. So I tried that, and it didn't help. It dies with mkdir -p -- ia64-unknown-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in ia64-unknown-linux-gnu/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... ia64-unknown-linux-gnu checking host system type... ia64-unknown-linux-gnu checking for ia64-unknown-linux-gnu-ar... ar checking for ia64-unknown-linux-gnu-lipo... lipo checking for ia64-unknown-linux-gnu-nm... /remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/nm checking for ia64-unknown-linux-gnu-ranlib... ranlib checking for ia64-unknown-linux-gnu-strip... strip checking whether ln -s works... yes checking for ia64-unknown-linux-gnu-gcc... /remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/lib/ -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/include -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. But ia64-unknown-linux-gnu/libgcc/config.log doesn't have any useful details. It has CC='/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/lib/ -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/include -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/sys-include' and ends with - #define PACKAGE_BUGREPORT #define PACKAGE_NAME GNU C Runtime Library #define PACKAGE_STRING GNU C Runtime Library 1.0 #define PACKAGE_TARNAME libgcc #define PACKAGE_VERSION 1.0 configure: exit 1 - and the exit 1 is the only sign that something is wrong.
Re: two more build results for gcc 4.3.2
Joe Buck [EMAIL PROTECTED] writes: But ia64-unknown-linux-gnu/libgcc/config.log doesn't have any useful details. It has CC='/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/lib/ -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/include -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/sys-include' and ends with - #define PACKAGE_BUGREPORT #define PACKAGE_NAME GNU C Runtime Library #define PACKAGE_STRING GNU C Runtime Library 1.0 #define PACKAGE_TARNAME libgcc #define PACKAGE_VERSION 1.0 configure: exit 1 - and the exit 1 is the only sign that something is wrong. These days autoconf likes to dump a whole bunch of cruft at the end of config.log. You have to look above all the cruft, which is usually most of the file, to find the actual failing test case. Ian
Re: two more build results for gcc 4.3.2
[ see parents for my build problems ] On Thu, Sep 04, 2008 at 02:00:11PM -0700, Ian Lance Taylor wrote: These days autoconf likes to dump a whole bunch of cruft at the end of config.log. You have to look above all the cruft, which is usually most of the file, to find the actual failing test case. Sure enough, it's the shared library; it appears that my attempt to set the path had a typo. That's what I thought the issue was. How embarrassing, sorry for the noise.
