[Bug c++/41180] New: can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

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


--
           Summary: can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dmarkman at mac dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

------- Comment #1 from dmarkman at mac dot com  2009-08-28 03:17 -------
Created an attachment (id=18440)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18440&action=view)
config.log for failed build

this is config.log for the failed build


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

------- Comment #2 from redi at gcc dot gnu dot org  2009-08-28 10:19 -------
(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.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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.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.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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

------- 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