[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" <gcc-bugzilla at gcc dot gnu dot org>]

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