Hi I'm not able to build gcc 4.4.1 on Snow Leopard Mac Pro ( gmp 4.3.1 and mpfr 2.4.1 were built without problem #gmp cd gmp-4.3.1 ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make make install make check #mpfr cd ../mpfr-2.4.1 ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make make install make check #gcc cd ../gcc-4.4.1 ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make make compalins about incompatible library arch. gmp and mpfr were built as x86_64 libraries I verified it with "file" command so I just forced some flags to be x86_64: setenv LDFLAGS "-arch x86_64" setenv CFLAGS "-arch x86_64" setenv CXXFLAGS "-arch x86_64" setenv CPPFLAGS "-arch x86_64" make clean make distclean ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make and after that I got another error: checking for i386-apple-darwin10.0.0-gcc... /Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/host-i386-apple-darwin10.0.0/gcc/xgcc -B/Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/host-i386-apple-darwin10.0.0/gcc/ -B/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/bin/ -B/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/lib/ -isystem /home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/include -isystem /home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/sys-include checking for suffix of object files... configure: error: in `/Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/i386-apple-darwin10.0.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2
Created attachment 18440 [details] config.log for failed build this is config.log for the failed build
(In reply to comment #0) > #gcc > cd ../gcc-4.4.1 > ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build > --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build is that command right? I think you will need to attach the libgcc/config.log as that seems to be where the problem is. You can use something like --build=i386-apple-darwin10.0.0 when configuring gmp, mpfr and gcc, to ensure they all agree on what to build.
Changing component, nothing to do with c++ front end
Remember that the compilers in Snow Leopard will execute as x86_64 code and generate the same by default on EMT64 capable hardware. However the uname output will still report i386 unless you are running the 64-bit kernel in Snow Leopard. The workaround is to just make sure you pass... -build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 to configure.
thanks for the answer. Here is what I did in the fresh new gcc-4.4.1 folder I issued ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build --enable-languages=c,c++ --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build --with-mpfr=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build -build=x86_64-apple-darwin10.0.0 --host=x86_64-apple-darwin10.0.0 --target=x86_64-apple-darwin10.0.0 and now I got another error: /Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/host-x86_64-apple-darwin10.0.0/prev-gcc/xgcc -B/Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/host-x86_64-apple-darwin10.0.0/prev-gcc/ -B/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/x86_64-apple-darwin10.0.0/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o cc1plus-dummy \ cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o i386-c.o darwin-c.o c-pretty-print.o c-opts.o c-pch.o incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o tree-inline.o dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build/lib -L/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build/lib -lmpfr -lgmp ld: duplicate symbol _init_inline_once in libbackend.a(tree-inline.o) and tree-inline.o collect2: ld returned 1 exit status make[3]: *** [cc1plus-dummy] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 and BTW, from the gcc-4.4.1 I called command: find . -name *.o | xargs file and I saw that majority of the .o files have x86_64 arch., but there are .o file with i386 (especially from prev-gcc/i386 and i386/libgcc folders) also I did try to build gcc with x86_64 kernel, unfortunately config.guess doesn't guess right, because uname -p still returns i386 only uname -m returns x86_64 I found that very confusing command arch also returns i386 and now I can say that building gcc on x86_64 kernel machine gave me the same duplication error thanks in advance
it should be --build, not -build as stated at http://gcc.gnu.org/install/configure.html do NOT build in the source directory, create a new directory to build in and run $SRCDIR/configure instead of ./configure
Actually this is a bug in Xcode 3.2's linker that I wasn't able to get Apple to fix (radar 6320843) "duplicate symbols from static libraries not properly ignored". The fix for gcc 4.4.1 and trunk is to apply the patch... --- gcc-4.4-20090327/gcc/cp/Make-lang.in.org 2009-03-27 20:58:00.000000000 -0400 +++ gcc-4.4-20090327/gcc/cp/Make-lang.in 2009-03-27 20:58:46.000000000 -0400 @@ -73,7 +73,7 @@ CXX_C_OBJS = attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o \ c-dump.o $(CXX_TARGET_OBJS) c-pretty-print.o c-opts.o c-pch.o \ incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o \ - c-gimplify.o c-omp.o tree-inline.o + c-gimplify.o c-omp.o # Language-specific object files for C++ and Objective C++. CXX_AND_OBJCXX_OBJS = cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o \ --- gcc-4.4-20090327/gcc/cp/Make-lang.in.orig 2009-03-27 21:04:25.000000000 -0400 +++ gcc-4.4-20090327/gcc/cp/Make-lang.in 2009-03-27 21:29:51.000000000 -0400 @@ -72,7 +72,7 @@ # Shared with C front end: CXX_C_OBJS = attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o \ c-dump.o $(CXX_TARGET_OBJS) c-pretty-print.o c-opts.o c-pch.o \ - incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o \ + incpath.o c-ppoutput.o c-cppbuiltin.o prefix.o \ c-gimplify.o c-omp.o # Language-specific object files for C++ and Objective C++. I considered submitting this for gcc 4.4.1 and trunk but figured it would be better to keep nagging Apple make their ld behave as a unix linker should.
Back to the issue of configure not properly detecting the target as x86_64-apple-darwin10 but grabbing i386-apple-darwin10 instead, one possible fix would be to have configure use 'sysctl -n hw.cpu64bit_capable' to test on darwin10 if the target is compiling x86_64 code. Configure can't blindly assume x86_64 on darwin10 because the first generation Intel Macs with non-EMT64 capable processors will generate 32-bit code from the system gcc.
When one builds with CC='gcc -m32', would be nice for config.guess to know this is i686-apple-darwin10. When using CC='gcc -m64', would be nice for config.guess to know this is x86_64-apple-darwin10. If ones makes those two work, then all the other various combinations just fall out.
thank you very much for all your comments first of all I fixed my typo and used --build instead of -build but that wasn't a problem after modifying Make-lang.in from gcc/cp folder (as Jack Howarth suggested) I was able to finish the build. I agree that apple should fix that bug, from other hand that patch should be available as well thank you very much for all your help
The following patch generated under gcc 4.4 branch is a first pass at correcting the default triplet detected under darwin10... Index: config.guess =================================================================== --- config.guess (revision 151196) +++ config.guess (working copy) @@ -1258,6 +1258,15 @@ exit ;; *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + main() + { + } +EOF + if test "`gcc -o $dummy $dummy.c; file $dummy | grep -c x86_64`" = 1 ; then + UNAME_PROCESSOR=x86_64 + fi case $UNAME_PROCESSOR in unknown) UNAME_PROCESSOR=powerpc ;; esac On my MacBook Pro under darwin10, which reports... uname -p i386 ...this generates... ./config.guess x86_64-apple-darwin10.0.0
Opps, the corrected proposed patch is... Index: config.guess =================================================================== --- config.guess (revision 151196) +++ config.guess (working copy) @@ -1258,6 +1258,15 @@ exit ;; *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + main() + { + } +EOF + if test "`$CC_FOR_BUILD -o $dummy $dummy.c; file $dummy | grep -c x86_64`" = 1 ; then + UNAME_PROCESSOR=x86_64 + fi case $UNAME_PROCESSOR in unknown) UNAME_PROCESSOR=powerpc ;; esac
We also need to make sure that the i[[3456789]]86-*-darwin* target pass -m32 to the compiler when building on Snow Leopard. This patch is untested but I believe is in the right direction... Index: configure.ac =================================================================== --- configure.ac (revision 151196) +++ configure.ac (working copy) @@ -1015,6 +1015,12 @@ i[[3456789]]86-*-sysv5*) host_makefile_frag="config/mh-sysv5" ;; + i[[3456789]]86-*-darwin*) + # gcc can default to x86_64 code generation, avoid that + if test "${build}" = "${host}"; then + tentative_cc="${CC-gcc} -m32" + fi + ;; i[[3456789]]86-*-dgux*) tentative_cc="gcc -Wall -ansi -D__using_DGUX" host_makefile_frag="config/mh-dgux386"
#13 looks fine. #14 needs a build to confirm it works. I've tested the style of #14 in the gcc-4.2.1 tree and it works as expected.
Oops, I mean #12 and #13. For #13, make sure there isn't an existing entry already. If there is, the code should be added to it.
Mike, No, there isn't any host cases for i[[3456789]]86-*-darwin* in that section of configure.ac only... powerpc-*-darwin*) host_makefile_frag="config/mh-ppc-darwin" ;; Interestingly, while Apple's gcc 4.2.1 has a mh-x86-darwin in this construct, a mh-x86-darwin file was never submitted for FSF gcc, FYI. I'll test this code later this week after I get my hands on the necessary fink autoconf 2.64 package to regenerate the topl-evel configure. FYI, we had that in fink but regressed it out for 2.63 because it was breaking too many other packages.
That file just has: # APPLE LOCAL file dynamic-no-pic # The -mdynamic-no-pic ensures that the compiler executable is built without # position-independent-code -- the usual default on Darwin. BOOT_CFLAGS=-g -O2 -mdynamic-no-pic in it. This just results in a faster compiler, otherwise, there should be no real change.
Actually comment 14 has it backwards. If we implement the config.guess correction so that the host reports the default code generation and execution as x86_64-apple-darwin*, we would need something like... Index: configure.ac =================================================================== --- configure.ac (revision 151196) +++ configure.ac (working copy) @@ -1015,6 +1015,12 @@ i[[3456789]]86-*-sysv5*) host_makefile_frag="config/mh-sysv5" ;; + x86_64-*-darwin*) + # gcc can default to x86_64 code generation, avoid that + if test "${build}" != "${host}"; then + tentative_cc="${CC-gcc} -m32" + fi + ;; i[[3456789]]86-*-dgux*) tentative_cc="gcc -Wall -ansi -D__using_DGUX" host_makefile_frag="config/mh-dgux386" instead. However this wouldn't be robust enough since if you only passed --target=x86_64-apple-darwin10, it would trigger the -m32 usage since the default triplet gets picked up as x86_64-apple-darwin10.0.0.
This appears to do what we want on Snow Leopard in combination with the config.guess patch... Index: configure.ac =================================================================== --- configure.ac (revision 151258) +++ configure.ac (working copy) @@ -1119,6 +1119,14 @@ rs6000-*-aix*) host_makefile_frag="config/mh-ppc-aix" ;; + x86_64-*-darwin*) + case "${target}" in + # avoid default x86_64 code generation + i[3456789]86-*-darwin*) + CC="${CC-gcc} -m32" + ;; + esac + ;; *-*-lynxos*) # /bin/cc is less than useful for our purposes. Always use GCC tentative_cc="/bin/gcc"
The patch in #19 is wrong. If you configure a x86->ppc64 compile, it would want to use -m32, which is wrong. We experimented with a change like that in #20 and it resulted in failures; I can't imagine any good coming from it. In short, CC isn't a variable that can be changed here, like this, only tentative_cc can be. I don't know what these two bits are trying to fix, so, I can't say what the right solution is.
Mike, The fix in comment 20 originated from your email to me... >On Aug 28, 2009, at 8:48 AM, Jack Howarth wrote: >> Can you take a look at PR41180 (specifically >> comment 9). I think we should propose a configure >> change for gcc 4.4.2 and trunk that utilizes >> 'sysctl -n hw.cpu64bit_capable' on darwin10 to >> set the triplet to x86_64-apple-darwin10 instead >> of i386-apple-darwin10 as is blindly done now. >> I am rather unfamilar with configure and was >> hoping you might have some suggestions on how >> this should be best done. > >Just fix config.guess to say x86_64-apple-darwin10, if `$CC t.c && file >a.out` == x86_64. >That gets most of it. Besides that, when targetting i686-apple-darwin, >$(CC) -m32 should be used, see: > > # APPLE LOCAL begin dynamic-no-pic > i[[3456789]]86-*-darwin*) > host_makefile_frag="config/mh-x86-darwin" > # gcc can default to x86_64 code generation, avoid that > if test "${build}" = "${host}"; then > CC="${CC-gcc} -m32" > fi > ;; > # APPLE LOCAL end dynamic-no-pic > >from configure.in. > You neglected to consider in the recommendation for the configure.(in/ac) change that the config.guess patch would change the case section where the -m32 option would be needed. The current config.guess will always report i386-apple-darwin whereas the proposed config.guess change would tether the processor name to the actual default code generation/execution which is properly x86_64 on darwin10. This means that the -m32 option would be applied in the x86_64 match of the case statement and only if the target was i[3456789]86-*-darwin*. So I don't understand how it could cause problems since it only triggers the addition of -m32 for i[3456789]86 targets. I did try substituting tentative_cc but I believe that wasn't causing -m32 to be used in the configure tests (but I'll revisit that issue). Outside of changing CC to tentative_cc, I think that the logic of the patch proposed in Comment 20 is correct but ONLY after the config.guess change proposed in http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00087.html is accepted upstream.
I should clarify that the proposed change in comment 20 only triggers if the host is x86_64-apple-darwin* (which would be the case once the config,guess change goes in) and will in that case only add -m32 to the options if the target matches i[[3456789]]86-*-darwin*. I don't see how that would accidentally trigger on any other cross compiles.
We could also add (as a separate patch) a change identical to what Apple uses in their gcc which only triggers on the i[[3456789]]86-*-darwin* host and target but this should be unnecessary after the config.guess change goes in. After the config.guess change, it would only serve to idiot-proof configure for the case of someone passing the i[[3456789]]86-*-darwin10 host on a Snow Leopard machine that is actually running and generating x86_64 binaries (and will be identified properly by the patched config.guess as x86_64-apple-darwin10).
Mike, I double checked and using tentative_cc doesn't results in a failure in configure at... checking for correct version of gmp.h... yes checking for correct version of mpfr.h... yes checking for the correct version of mpc.h... no checking for the correct version of the gmp/mpfr libraries... no configure: error: Building GCC requires GMP 4.2+ and MPFR 2.3.2+. Try the --with-gmp and/or --with-mpfr options to specify their locations. Copies of these libraries' source code can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP and/or MPFR from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages. Only if I use CC like the Apple gcc's configure does the -m32 get passed all the way through to the gmp test. There must have been a reason why Apple used CC rather than tentative_cc here.
First, config.guess is orthogonal to the entire discussion, because of that, we never need to mention it again. Next, we do a case analysis of every combination of host/target and build… We engineer each case to work as desired. Once that is done, you'll discover that we absolutely do need the i386 case to set -m32. If that isn't done, the compiler defaults to 64-bit, and that runs counter to the command implied by the i386, which is to generate 32-bit code. So, the fragment I sent is absolutely required, unchanged. You can know this is true by configure --build=i386-apple-darwin10 on a 64-bit SL box and running file on gcc/expr.o. If it is 64-bit, it is wrong. -m32 should never be set because the x86_64 case. x86_64 means 64-bit, so, the most it implies is -m64. For this reason, #19 must be wrong. x86_64 implying -m64 is useful for gcc's that default to 32-bit code-gen. I don't have that in my tree, as I don't have to worry much about older systems and older compilers. For the FSF tree, it would be nice to have that. You can know this is true by configuring --build=x86_64-apple-darwin on a Leopard box (where gcc defaults to 32-bit) and running file on gcc/expr.o. If it is 32-bit, it is wrong. darwin10 supports and runs on 32-bit only processors. In that case, x86_64 isn't the default code-gen, contrary to your statement in #22. It is improper to test target in #20, as target has no influence. --host=i386-apple-darwin --target=arm-elf implies -m32. Build one, then run file gcc/expr.o. If that file is 64-bit, it is wrong. The changes to configure.ac are independent of config.guess, so your assertion that the changes are only appropriate after config.guess is accepted, is wrong. You can see this by configure --build=i386-apple-darwin10 and running file gcc/expr.o and noticing it is wrong currently on SL. It is says 64-bit, it is wrong. For the comment in #24, no, that isn't its only purpose. The purpose of it would be to allow one to configure --host=i386-apple-darwin10 --build=i386-apple-darwin10, and have gcc do what it is told to do, which is to generate 32-bit binaries. Now, all that aside, you only need to change the patches I suggested, if there is an error in them. You've not identified one error, therefore you don't need to change them. If you want to change them, please explain the error. Lastly, tentative_cc won't work as well as setting CC. My comment in #15 is wrong, CC must be used. As for the libraries. You have to build them appropriately, and give to gcc, the appropriate libs. I build them universal, so what I give gcc is trivially, always good. If you build just one architecture, you have to build the libraries with the same 32/64-bitness as you want to build the compiler.
Mike, Regarding passing -m32 within the x86_64 host case, I was considering the case of trying to cross compile the i686-apple-darwin10 target on the x86_64-apple-darwin10 host. While this sounds odd, we currently do this on i386 fink for 10.6 (but we cheat by using wrappers for the compilers that pass -m32 and explicitly pass --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=i686-apple-darwin10 to gcc's configure). Without my proposed patch in comment 10, if the user passed... --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 the i[[3456789]]86-*-darwin* host case won't be triggered but rather the absent x86_64-*-darwin* host case. Without the patch, no -m32 will be added to CC and the compiler will attempt to build the i686-apple-darwin10 compiler with the default m64 code generation. If I remove the change from comment 20 and use the stock configure from gcc trunk with... ../gcc/configure --prefix=/Users/howarth/dist --enable-languages=c,c++,fortran,objc,java --with-arch=nocona --with-tune=generic --host=x86_64-apple-darwin10 --target=i686-apple-darwin9 --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib where /sw is a i386 fink installation containing i386 binaries for gmp/mpfr, I get the configure failure... checking for correct version of gmp.h... yes checking for correct version of mpfr.h... yes checking for the correct version of mpc.h... no checking for the correct version of the gmp/mpfr libraries... no configure: error: Building GCC requires GMP 4.2+ and MPFR 2.3.2+. Try the --with-gmp and/or --with-mpfr options to specify their locations. Copies of these libraries' source code can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP and/or MPFR from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages. Adding Apple's patch as... @@ -3645,6 +3653,12 @@ powerpc-*-darwin*) host_makefile_frag="config/mh-ppc-darwin" ;; + i[3456789]86-*-darwin*) + # gcc can default to x86_64 code generation, avoid that + if test "${build}" = "${host}"; then + CC="${CC-gcc} -m32" + fi + ;; powerpc-*-aix*) host_makefile_frag="config/mh-ppc-aix" ;; won't help in this case because 1) the host is set to x86_64-apple-darwin10 so this case never executes and 2) the target and host don't match anyway to set CC to have -m32. I would also remind you that the Apple system compiler in SL shows... Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646~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 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) which is exactly the triplet combination for --host and --target that I am looking at. Only if I add my proposed patch in Comment 20 does configure complete properly for the --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 combination producing 32-bit binaries. [Macintosh-2:~/work] howarth% ../gcc/configure --prefix=/Users/howarth/dist --enable-languages=c,c++,fortran,objc,java --with-arch=nocona --with-tune=generic --host=x86_64-apple-darwin10 --target=i686-apple-darwin9 --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking build system type... x86_64-apple-darwin10.0.0 checking host system type... x86_64-apple-darwin10 checking target system type... i686-apple-darwin9 checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/bin/sed checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking for x86_64-apple-darwin10-gcc... gcc -m32 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m32 accepts -g... yes checking for gcc -m32 option to accept ISO C89... none needed checking for x86_64-apple-darwin10-g++... no checking for x86_64-apple-darwin10-c++... no checking for x86_64-apple-darwin10-gpp... no checking for x86_64-apple-darwin10-aCC... no checking for x86_64-apple-darwin10-CC... no checking for x86_64-apple-darwin10-cxx... no checking for x86_64-apple-darwin10-cc++... no checking for x86_64-apple-darwin10-cl.exe... no checking for x86_64-apple-darwin10-FCC... no checking for x86_64-apple-darwin10-KCC... no checking for x86_64-apple-darwin10-RCC... no checking for x86_64-apple-darwin10-xlC_r... no checking for x86_64-apple-darwin10-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for x86_64-apple-darwin10-gnatbind... no checking for gnatbind... no checking for x86_64-apple-darwin10-gnatmake... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... yes checking for correct version of mpfr.h... yes checking for the correct version of mpc.h... no checking for the correct version of the gmp/mpfr libraries... yes checking for version 0.10 of PPL... yes checking for correct version of CLooG... yes The following languages will be built: c,c++,fortran,java,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libada gnattools (Any other directories should still work fine.) rm: conftest.dSYM: is a directory checking for bison... bison -y checking for bison... bison checking for gm4... gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... no checking for x86_64-apple-darwin10-ar... no checking for x86_64-apple-darwin10-as... no checking for x86_64-apple-darwin10-dlltool... no checking for ld... (cached) /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld checking for x86_64-apple-darwin10-ld... (cached) /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld checking for x86_64-apple-darwin10-lipo... no checking for x86_64-apple-darwin10-nm... no checking for x86_64-apple-darwin10-ranlib... no checking for x86_64-apple-darwin10-strip... no checking for x86_64-apple-darwin10-windres... no checking for x86_64-apple-darwin10-windmc... no checking for x86_64-apple-darwin10-objcopy... no checking for x86_64-apple-darwin10-objdump... no checking for i686-apple-darwin9-cc... no checking for i686-apple-darwin9-gcc... no checking for i686-apple-darwin9-c++... no checking for i686-apple-darwin9-g++... no checking for i686-apple-darwin9-cxx... no checking for i686-apple-darwin9-gxx... no checking for i686-apple-darwin9-gcc... no checking for i686-apple-darwin9-gcj... no checking for i686-apple-darwin9-gfortran... no checking for i686-apple-darwin9-ar... no checking for i686-apple-darwin9-as... no checking for i686-apple-darwin9-dlltool... no checking for i686-apple-darwin9-ld... no checking for i686-apple-darwin9-lipo... no checking for i686-apple-darwin9-nm... no checking for i686-apple-darwin9-objdump... no checking for i686-apple-darwin9-ranlib... no checking for i686-apple-darwin9-strip... no checking for i686-apple-darwin9-windres... no checking for i686-apple-darwin9-windmc... no checking where to find the target ar... pre-installed checking where to find the target as... pre-installed checking where to find the target cc... pre-installed checking where to find the target c++... pre-installed checking where to find the target c++ for libstdc++... pre-installed checking where to find the target dlltool... pre-installed checking where to find the target gcc... pre-installed checking where to find the target gcj... pre-installed checking where to find the target gfortran... pre-installed checking where to find the target ld... pre-installed checking where to find the target lipo... pre-installed checking where to find the target nm... pre-installed checking where to find the target objdump... pre-installed checking where to find the target ranlib... pre-installed checking where to find the target strip... pre-installed checking where to find the target windres... pre-installed checking where to find the target windmc... pre-installed checking whether to enable maintainer-specific portions of Makefiles... no checking whether -fkeep-inline-functions is supported... yes configure: creating ./config.status config.status: creating Makefile
Subject: Re: can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6 On Thu, 3 Sep 2009, howarth at nitro dot med dot uc dot edu wrote: > Mike, > Regarding passing -m32 within the x86_64 host case, I was considering the > case of trying to cross compile the i686-apple-darwin10 target on the > x86_64-apple-darwin10 host. While this sounds odd, we currently do this on > i386 fink for 10.6 (but we cheat by using wrappers for the compilers that pass > -m32 and explicitly pass --build=i686-apple-darwin10 --host=i686-apple-darwin10 > --target=i686-apple-darwin10 to gcc's configure). Without my proposed patch in > comment 10, if the user passed... > > --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 > > the i[[3456789]]86-*-darwin* host case won't be triggered but rather the absent > x86_64-*-darwin* host case. Without the patch, no -m32 will be added to CC > and the compiler will attempt to build the i686-apple-darwin10 compiler with > the default m64 code generation. If you pass those options, you are asking for the compiler that is built to be a 64-bit binary itself, but to default to generating 32-bit code. CC at top level is the compiler for the host, so should be a 64-bit compiler and no -m32 should be added; adding -m32 is actually *wrong* here. No pre-existing compiler generating 32-bit code is required by this configuration (presuming that the build system is also x86_64-apple-darwin10, the same as the host). If you wanted a compiler that was a 32-bit binary, as well as generating 32-bit code, you'd specify --host=i686-apple-darwin10, and pass a 32-bit CC setting. > If I remove the change from comment 20 and use the stock configure from gcc > trunk with... > > ../gcc/configure --prefix=/Users/howarth/dist > --enable-languages=c,c++,fortran,objc,java --with-arch=nocona > --with-tune=generic --host=x86_64-apple-darwin10 --target=i686-apple-darwin9 > --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib > > where /sw is a i386 fink installation containing i386 binaries for gmp/mpfr, I > get the configure failure... > > checking for correct version of gmp.h... yes > checking for correct version of mpfr.h... yes > checking for the correct version of mpc.h... no > checking for the correct version of the gmp/mpfr libraries... no > configure: error: Building GCC requires GMP 4.2+ and MPFR 2.3.2+. > Try the --with-gmp and/or --with-mpfr options to specify their locations. If you are using --host=x86_64-apple-darwin10, you clearly need 64-bit copies of GMP and MPFR in the appropriate locations. > Adding Apple's patch as... > > @@ -3645,6 +3653,12 @@ > powerpc-*-darwin*) > host_makefile_frag="config/mh-ppc-darwin" > ;; > + i[3456789]86-*-darwin*) > + # gcc can default to x86_64 code generation, avoid that > + if test "${build}" = "${host}"; then > + CC="${CC-gcc} -m32" > + fi > + ;; This also seems wrong (or at least unnecessary). If the user configures --host=i686-apple-darwin10 when the host compiler defaults to 64-bit code generation, the user has passed incorrect configure options. It is the responsibility of the user in that case to set CC="gcc -m32", not the responsibility of GCC. This is just the same as if you wish to bootstrap a 32-bit compiler on x86_64-linux-gnu: you have to set CC appropriately yourself, as well as passing suitable configure options. Such a bootstrap works fine, and if you are doing something different here for Darwin from what is done for the GNU/Linux case that is a good sign you are doing something wrong.
Joesph, Thanks for the clarifications. The origin of the patch in Comment 20 was Mike's suggestion that we needed the change from Apple's gcc in Comment 22. It would appear neither are really necessary or desired. For i386 fink on 10.6, we take exactly the approach you suggest (using compiler wrappers in our case) to pass -m32 through CC.
I admit that having gcc automagically add -m32 isn't strictly needed, the user can do that. The problem is when they don't do that. What behavior do we want? We can pick: 1) Just work. 2) Fail immediately, telling them they did it wrong. 3) Grind away for hours, just to fail in some obscure hard to understand way Status quo is #3. Now, we have the choice to do this, or to do 1. Argue against 1; it is import to fail in some obscure way because... I have never see a compelling argument. I did the change up as I was supporting users that grew tied of it failing all the time. I grew tied of it failing all the time. For me, it's an easy choice. The cost of the few lines is well worth the benefit to me.
Subject: Bug 41180 Author: fxcoudert Date: Wed Sep 9 08:14:36 2009 New Revision: 151554 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151554 Log: PR bootstrap/41180 * gcc/cp/Make-lang.in: Remove redundant code from linkage for darwin10. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in
Subject: Bug 41180 Author: fxcoudert Date: Wed Sep 9 08:46:32 2009 New Revision: 151555 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151555 Log: PR bootstrap/41180 * gcc/cp/Make-lang.in: Remove redundant code from linkage for darwin10. Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/Make-lang.in
*** Bug 41525 has been marked as a duplicate of this bug. ***
Fixed in 4.4.2.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.