User account creation filtered due to spam.

Bug 41180 - can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
Summary: can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.4.1
: P3 normal
Target Milestone: 4.4.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 41525 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-28 03:13 UTC by Dmitry Markman
Modified: 2014-02-16 13:14 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
config.log for failed build (6.59 KB, text/plain)
2009-08-28 03:17 UTC, Dmitry Markman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Markman 2009-08-28 03:13:34 UTC
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
Comment 1 Dmitry Markman 2009-08-28 03:17:10 UTC
Created attachment 18440 [details]
config.log for failed build

this is config.log for the failed build
Comment 2 Jonathan Wakely 2009-08-28 10:19:47 UTC
(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.
Comment 3 Jonathan Wakely 2009-08-28 10:23:45 UTC
Changing component, nothing to do with c++ front end
Comment 4 Jack Howarth 2009-08-28 13:28:30 UTC
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.
Comment 5 Dmitry Markman 2009-08-28 14:36:14 UTC
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




Comment 6 Dmitry Markman 2009-08-28 14:37:38 UTC
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
Comment 7 Jonathan Wakely 2009-08-28 15:01:58 UTC
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
Comment 8 Jack Howarth 2009-08-28 15:12:07 UTC
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.
Comment 9 Jack Howarth 2009-08-28 15:31:56 UTC
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.
Comment 10 mrs@gcc.gnu.org 2009-08-28 16:14:13 UTC
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.
Comment 11 Dmitry Markman 2009-08-28 17:28:35 UTC
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
Comment 12 Jack Howarth 2009-08-29 01:32:10 UTC
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
Comment 13 Jack Howarth 2009-08-29 01:40:48 UTC
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
Comment 14 Jack Howarth 2009-08-29 02:19:33 UTC
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"
Comment 15 Mike Stump 2009-08-31 17:35:40 UTC
#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.
Comment 16 Mike Stump 2009-08-31 17:37:49 UTC
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.
Comment 17 Jack Howarth 2009-08-31 18:04:18 UTC
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.
Comment 18 Mike Stump 2009-08-31 20:37:24 UTC
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.
Comment 19 Jack Howarth 2009-09-01 04:00:29 UTC
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.
Comment 20 Jack Howarth 2009-09-01 04:23:27 UTC
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"
Comment 21 Mike Stump 2009-09-02 20:37:39 UTC
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.
Comment 22 Jack Howarth 2009-09-02 21:41:03 UTC
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.
Comment 23 Jack Howarth 2009-09-02 21:44:05 UTC
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.
Comment 24 Jack Howarth 2009-09-02 22:22:07 UTC
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).
Comment 25 Jack Howarth 2009-09-02 23:37:10 UTC
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.
Comment 26 Mike Stump 2009-09-03 00:20:26 UTC
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.
Comment 27 Jack Howarth 2009-09-03 00:56:39 UTC
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

Comment 28 joseph@codesourcery.com 2009-09-03 11:04:09 UTC
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.

Comment 29 Jack Howarth 2009-09-03 13:00:16 UTC
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.
Comment 30 Mike Stump 2009-09-04 01:49:58 UTC
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.
Comment 31 Francois-Xavier Coudert 2009-09-09 08:15:28 UTC
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

Comment 32 Francois-Xavier Coudert 2009-09-09 08:46:51 UTC
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

Comment 33 Andrew Pinski 2009-09-30 19:40:00 UTC
*** Bug 41525 has been marked as a duplicate of this bug. ***
Comment 34 Andrew Pinski 2009-09-30 19:41:03 UTC
Fixed in 4.4.2.
Comment 35 Jackie Rosen 2014-02-16 13:14:10 UTC Comment hidden (spam)