[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC||jackie.rosen at hushmail dot com --- Comment #35 from Jackie Rosen jackie.rosen at hushmail dot com --- *** 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.
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #33 from pinskia at gcc dot gnu dot org 2009-09-30 19:40 --- *** Bug 41525 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pgbackup at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #34 from pinskia at gcc dot gnu dot org 2009-09-30 19:41 --- Fixed in 4.4.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2009-09-09 08:15 --- Subject: Bug 41180 Author: fxcoudert Date: Wed Sep 9 08:14:36 2009 New Revision: 151554 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #32 from fxcoudert at gcc dot gnu dot org 2009-09-09 08:46 --- Subject: Bug 41180 Author: fxcoudert Date: Wed Sep 9 08:46:32 2009 New Revision: 151555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #28 from joseph at codesourcery dot com 2009-09-03 11:04
---
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #30 from mrs at apple dot com 2009-09-04 01:49 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #21 from mrs at apple dot com 2009-09-02 20:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-09-02 21:44 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-09-02
21:41 ---
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-09-02 22:22 --- 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). -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-09-02 23:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #26 from mrs at apple dot com 2009-09-03 00:20 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-09-03
00:56 ---
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++...
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #16 from mrs at apple dot com 2009-08-31 17:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #15 from mrs at apple dot com 2009-08-31 17:35 --- #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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-08-31 18:04 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #18 from mrs at apple dot com 2009-08-31 20:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2009-09-01
04:00 ---
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2009-09-01
04:23 ---
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-28 10:23 --- Changing component, nothing to do with c++ front end -- redi at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-08-28 13:28 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #5 from dmarkman at mac dot com 2009-08-28 14:36 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #6 from dmarkman at mac dot com 2009-08-28 14:37 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-28 15:01 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-08-28 15:12 --- 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.org2009-03-27 20:58:00.0 -0400 +++ gcc-4.4-20090327/gcc/cp/Make-lang.in2009-03-27 20:58:46.0 -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.0 -0400 +++ gcc-4.4-20090327/gcc/cp/Make-lang.in2009-03-27 21:29:51.0 -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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-08-28 15:31 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #10 from mrs at gcc dot gnu dot org 2009-08-28 16:14 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #11 from dmarkman at mac dot com 2009-08-28 17:28 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-08-29
01:32 ---
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-08-29
01:40 ---
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-08-29
02:19 ---
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
