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

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

[dmarkman at mac dot com]

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

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

[dmarkman at mac dot com]

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

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

[redi at gcc dot gnu dot org]

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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[redi at gcc dot gnu dot org]

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

[howarth at nitro dot med dot uc dot edu]

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

[dmarkman at mac dot com]

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

[dmarkman at mac dot com]

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

[redi at gcc dot gnu dot org]

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

[howarth at nitro dot med dot uc dot edu]

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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

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

[mrs at gcc dot gnu dot org]

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

[dmarkman at mac dot com]

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

[howarth at nitro dot med dot uc dot edu]

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

[howarth at nitro dot med dot uc dot edu]

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

[howarth at nitro dot med dot uc dot edu]

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

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

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

[mrs at apple dot com]

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

[howarth at nitro dot med dot uc dot edu]

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

[mrs at apple dot com]

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

[howarth at nitro dot med dot uc dot edu]

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

[howarth at nitro dot med dot uc dot edu]

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

[mrs at apple dot com]

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

[howarth at nitro dot med dot uc dot edu]

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

[howarth at nitro dot med dot uc dot edu]

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

[howarth at nitro dot med dot uc dot edu]

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

[howarth at nitro dot med dot uc dot edu]

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

[mrs at apple dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]



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

[howarth at nitro dot med dot uc dot edu]

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


-- 


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

[joseph at codesourcery dot com]

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

[howarth at nitro dot med dot uc dot edu]

------- Comment #29 from howarth at nitro dot med dot uc dot edu  2009-09-03 13:00 -------
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.


-- 


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

[mrs at apple dot com]

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

[fxcoudert at gcc dot gnu dot org]

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


-- 


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

[fxcoudert at gcc dot gnu dot org]

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


-- 


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

[pinskia at gcc dot gnu dot org]

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

[pinskia at gcc dot gnu dot org]

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

[jackie.rosen at hushmail dot com]

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.