We still have some configure.ac and configure scripts that are hardcoded for darwin9 only so that builds of the x86_64-apple-darwin10 target fail to configure for the java language. I believe the following change should be sufficient... Index: configure =================================================================== --- configure (revision 142271) +++ configure (working copy) @@ -2210,7 +2210,7 @@ *-*-chorusos) noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}" ;; - powerpc-*-darwin* | x86_64-*-darwin9*) + powerpc-*-darwin* | x86_64-*-darwin[912]*) noconfigdirs="$noconfigdirs ld gas gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; Index: configure.ac =================================================================== --- configure.ac (revision 142271) +++ configure.ac (working copy) @@ -446,7 +446,7 @@ *-*-chorusos) noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}" ;; - powerpc-*-darwin* | x86_64-*-darwin9*) + powerpc-*-darwin* | x86_64-*-darwin[912]*) noconfigdirs="$noconfigdirs ld gas gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; Index: libjava/configure.host =================================================================== --- libjava/configure.host (revision 142271) +++ libjava/configure.host (working copy) @@ -295,11 +295,11 @@ slow_pthread_self= can_unwind_signal=no ;; - i?86-*-darwin9*) + i?86-*-darwin[912]*) can_unwind_signal=yes DIVIDESPEC=-f%{m32:no-}%{!m32:%{!m64:no-}}%{m64:}use-divide-subroutine ;; - x86_64-*-darwin9*) + x86_64-*-darwin[912]*) enable_hash_synchronization_default=yes slow_pthread_self= can_unwind_signal=yes Index: libjava/configure.ac =================================================================== --- libjava/configure.ac (revision 142271) +++ libjava/configure.ac (working copy) @@ -1632,7 +1632,7 @@ m68*-*-linux*) SIGNAL_HANDLER=include/dwarf2-signal.h ;; - powerpc*-*-darwin* | i?86-*-darwin9* | x86_64-*-darwin9*) + powerpc*-*-darwin* | i?86-*-darwin[912]* | x86_64-*-darwin[912]*) SIGNAL_HANDLER=include/darwin-signal.h ;; powerpc*-*-aix*) Index: libjava/configure =================================================================== --- libjava/configure (revision 142271) +++ libjava/configure (working copy) @@ -27517,7 +27517,7 @@ m68*-*-linux*) SIGNAL_HANDLER=include/dwarf2-signal.h ;; - powerpc*-*-darwin* | i?86-*-darwin9* | x86_64-*-darwin9*) + powerpc*-*-darwin* | i?86-*-darwin[912]* | x86_64-*-darwin[912]*) SIGNAL_HANDLER=include/darwin-signal.h ;; powerpc*-*-aix*) Testing now on x86_64-apple-darwin10.
This doesn't seem to be sufficient... MLIBS=`/Users/howarth/work/./gcc/xgcc -B/Users/howarth/work/./gcc/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/bin/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/lib/ -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/include -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/sys-include --print-multi-lib \ | sed -e 's/;.*$//' -e '/^\.$/d'` ; \ for mlib in $MLIBS ; do \ strip -o libgcc_s.10.4.dylib_T${mlib} \ -s ../../../gcc/libgcc/../gcc/config/i386/darwin-libgcc.10.4.ver -c -u \ ../${mlib}/libgcc/${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \ done ranlib: file: libgcc_eh.a(unwind-sjlj.o) has no symbols ranlib -c libgcc_eh.a lipo -output libgcc_s.10.4.dylib -create libgcc_s.10.4.dylib_T* ranlib: file: libgcc_eh.a(unwind-sjlj.o) has no symbols strip -o libgcc_s.10.5.dylib_T \ -s ../../../gcc/libgcc/../gcc/config/i386/darwin-libgcc.10.5.ver -c -u \ ./libgcc_s.1.dylib.tmp lipo: libgcc_s.10.4.dylib_T and libgcc_s.10.4.dylib_Tx86_64 have the same architectures (x86_64) and can't be in the same fat output file make[3]: *** [libgcc_s.10.4.dylib] Error 1 make[3]: *** Waiting for unfinished jobs.... MLIBS=`/Users/howarth/work/./gcc/xgcc -B/Users/howarth/work/./gcc/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/bin/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/lib/ -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/include -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/sys-include --print-multi-lib \ | sed -e 's/;.*$//' -e '/^\.$/d'` ; \ for mlib in $MLIBS ; do \ strip -o libgcc_s.10.5.dylib_T${mlib} \ -s ../../../gcc/libgcc/../gcc/config/i386/darwin-libgcc.10.5.ver -c -u \ ../${mlib}/libgcc/${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \ done lipo -output libgcc_s.10.5.dylib -create libgcc_s.10.5.dylib_T* lipo: libgcc_s.10.5.dylib_T and libgcc_s.10.5.dylib_Tx86_64 have the same architectures (x86_64) and can't be in the same fat output file make[3]: *** [libgcc_s.10.5.dylib] Error 1 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 using... ../gcc/configure --prefix=/Users/howarth/inst_gcc --enable-languages=c,c++,fortran,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 Using the darwin9 targets fail as well under darwin10. I suspect this breakage in the multilib is due to the fact that the gcc compiler now creates x86_64 code by default so we are likely missing some instances of -m32 which weren't required for the multilib bootstrap to work before.
Created attachment 16792 [details] failed multilib bootstrap from x86_64-apple-darwin10 I am attaching the failed bootstrap log with my proposed patch in use in case someone who understands the multilib bootstrap can stop where things are going wrong. I assume the x86_64-apple-darwin* multilib should be an inverse of the i386-apple-darwin* multilib. That is with a i386 subdirectory instead of a x86_64 subdirectory for the multilib created.
I should also note that the gmp and libmpfr1 used in these builds are x86_64 code of course.
../gcc/configure --prefix=/Users/howarth/inst_gcc --enable-languages=c,c++,fortran,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=i686-apple-darwin10 makes it pass stage1 and it appears that the bootstrap will complete with that triplet. So the problem appears to be specific to x86_64-apple-darwin* when the system compiler generates x86_64 by default. I suspect that both triplets end up passing -m64 for the x86_64 subdirectory but nothing for the toplevel libgcc build. We need to force -m32 for the toplevel libgcc, no?
Ah, I see the problem in the config.log. The inaccurate output of uname under the i386 kernel on a EMT64 chipset is confusing configure such that... $ ../gcc/configure --prefix=/Users/howarth/inst_gcc --enable-languages=c,c++,fortran,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 gets converted to Configured with: /var/tmp/gcc/gcc-5626~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 I'll try substituting a wrapper for uname that correctly outputs x86_64. Hopefully that will fix the multilib problems for the moment.
The uname output looks like a red herring. I substituted a script for uname that executes... #!/bin/sh uname_aside "$@" | /usr/bin/sed 's/i386/x86_64/' and the build still fails. I wonder if we could fix this with a passed-m32 flag on LIBGCC2_CFLAGS?
A starting point would be this: [wolfram:head/gcc/gcc] andreast% svn diff config/i386/t-darwin64 Index: config/i386/t-darwin64 =================================================================== --- config/i386/t-darwin64 (revision 142282) +++ config/i386/t-darwin64 (working copy) @@ -1,2 +1,8 @@ LIB2_SIDITI_CONV_FUNCS=yes LIB2FUNCS_EXTRA = $(srcdir)/config/darwin-64.c + +MULTILIB_OPTIONS = m32 +MULTILIB_DIRNAMES = xxx /* to be defined? */ + +LIBGCC = stmp-multilib +INSTALL_LIBGCC = install-multilib
Thanks! With your patch, gcc now makes it into stage 2 and is still building. I would suggest we use... MULTILIB_DIRNAMES = IA32 as Apple often using I386 but also builds for i686-apple-darwin as well. I thnk IA32 is more honest since it avoids declaring the exact processor type. ps This is without any corrections to the bogus uname output.
Andreas, Can you try the proposed patch on darwin9 for the x86-64-apple-darwin9 target? I will do a complete make check on darwin10 with the x86_64-apple-darwin10 triplet. I am surprised by this issue as I was sure folks were doing x86_64-apple-darwin multilib builds already. Thanks again for the fix.
At the time I did x86_64-apple-darwin* stuff I asked apple people if they intend to do multilib on this target, the answer was no. So I did not bother any longer. I do not know if IA32 is correct. I use i386 for the test now. Even this is not ok. But nevertheless I can complete a multilib build including test on 32/64-bit. I'll post the results on the usual place.
Apple wasn't concerned about the multilib issue since they do everything as lipo files. So I suspect it is rather academic on what we choice for the 32-bit subdirectory name.
The bootstrap is failing at... make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" "TARGET_SUBDIR=x86_64-apple-darwin10" "bindir=/Users/howarth/inst_gcc/bin" "datadir=/Users/howarth/inst_gcc/share" "exec_prefix=/Users/howarth/inst_gcc" "includedir=/Users/howarth/inst_gcc/include" "datarootdir=/Users/howarth/inst_gcc/share" "docdir=/Users/howarth/inst_gcc/share/doc" "infodir=/Users/howarth/inst_gcc/info" "pdfdir=/Users/howarth/inst_gcc/share/doc" "htmldir=/Users/howarth/inst_gcc/share/doc" "libdir=/Users/howarth/inst_gcc/lib" "libexecdir=/Users/howarth/inst_gcc/libexec" "lispdir=" "localstatedir=/Users/howarth/inst_gcc/var" "mandir=/Users/howarth/inst_gcc/man" "oldincludedir=/usr/include" "prefix=/Users/howarth/inst_gcc" "sbindir=/Users/howarth/inst_gcc/sbin" "sharedstatedir=/Users/howarth/inst_gcc/com" "sysconfdir=/Users/howarth/inst_gcc/etc" "tooldir=/Users/howarth/inst_gcc/x86_64-apple-darwin10" "build_tooldir=/Users/howarth/inst_gcc/x86_64-apple-darwin10" "target_alias=x86_64-apple-darwin10" "BISON=bison" "CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" "EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=gm4" "MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAGE1_CFLAGS=-g -fkeep-inline-functions" "STAGE1_CHECKING=--enable-checking=yes,types" "STAGE1_LANGUAGES=c" "STAGE2_CFLAGS=-g -O2" "STAGE3_CFLAGS=-g -O2" "STAGE4_CFLAGS=-g -O2" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC_FOR_TARGET=/Users/howarth/work8/./gcc/xgcc -B/Users/howarth/work8/./gcc/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/bin/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/lib/ -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/include -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/sys-include" "CFLAGS_FOR_TARGET=-g -O2" "CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/Users/howarth/work8/./gcc/g++ -B/Users/howarth/work8/./gcc/ -nostdinc++ -L/Users/howarth/work8/x86_64-apple-darwin10/libstdc++-v3/src -L/Users/howarth/work8/x86_64-apple-darwin10/libstdc++-v3/src/.libs -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/bin/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/lib/ -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/include -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/sys-include" "CXXFLAGS_FOR_TARGET=-g -O2" "DLLTOOL_FOR_TARGET=dlltool" "GCJ_FOR_TARGET=/Users/howarth/work8/./gcc/gcj -B/Users/howarth/work8/./gcc/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/bin/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/lib/ -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/include -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/sys-include" "GFORTRAN_FOR_TARGET=/Users/howarth/work8/./gcc/gfortran -B/Users/howarth/work8/./gcc/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/bin/ -B/Users/howarth/inst_gcc/x86_64-apple-darwin10/lib/ -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/include -isystem /Users/howarth/inst_gcc/x86_64-apple-darwin10/sys-include" "LD_FOR_TARGET=/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-g -O2" "LIBCXXFLAGS_FOR_TARGET=-g -O2 -fno-implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib -c" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc" "`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000" compare rm -f stage_current Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./gcc.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2
Why is it okay for cc1-checksum.o and cc1plus-checksum.o to differ but not gcc.o?
gcc.o differing is severe, while *checksum.o depend on some version information differing. I propose to do a real clean build. No build over build. My build on x86_64-apple-darwin9 is in the last stage, linking libjava and afterwards we enter testing.
It may be due to another patch I was testing. I am doing a clean bootstrap without the other patches.
The problem was a dirty build directory. A clean bootstrap has completed and a complete make check for -m32 and -m64 is underway under darwin10.
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02671.html
Should be fixed: http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00125.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00124.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00068.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00067.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00066.html http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00065.html Message 65 and 67 are for completeness.