request for configure clarifications on darwin10

[Toby Peterson]

Removing autoconf from cc for this reply...

On Tue, Sep 15, 2009 at 16:20, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>    Could we please get an expert opinion on the proper
> approach for handling the darwin10 targets with configure.
> As darwin10 is a hybrid OS which runs a 32-bit kernel but
> executes 64-bit binaries on EMT64 capable hardware, the reported
> architecture returned by the current config.guess can
> be in error (reporting i386-apple-darwin10 while the
> system compiler, gcc-4.2, is executing and generating
> x86_64 code). Ben Elliston is currently evaluating a
> proposed patch I sent to solve this issue...
>
> --- config.guess.orig   2009-09-12 20:13:05.000000000 -0400
> +++ config.guess        2009-09-12 20:14:07.000000000 -0400
> @@ -1259,6 +1259,24 @@
>     *:Darwin:*:*)
>        UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
>        case $UNAME_PROCESSOR in
> +           i386)
> +               eval $set_cc_for_build
> +               if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
> +                 sed 's/^                //' << EOF >$dummy.c
> +                 #if defined(__LP64__)
> +                 main()
> +                 {
> +                 }
> +                 #endif
> +EOF
> +                 if test `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep -c main` = 1 ; then
> +                     UNAME_PROCESSOR=x86_64
> +                 fi
> +               else
> +                 if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then
> +                   UNAME_PROCESSOR=x86_64
> +                 fi
> +               fi ;;
>            unknown) UNAME_PROCESSOR=powerpc ;;
>        esac
>        echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
>
> ...which tests the compiler code generation if one is present and
> otherwise checks the default code execution with sysctl.

Patch feedback:

(1) Wouldn't it be easier to grep the output of "$CC -E -dM -xc /dev/null" ?
(2) sysctl check is wrong, as that sysctl is exported regardless. I
suggest checking the output of "sysctl -n hw.cpu64bit_capable", it'll
be 0 or 1.

>   In the meanwhile, projects like MacPorts are currently trying to
> deal with these issues. There seems to be some major confusion about
> what is acceptable to do with configure in this case. Specifically
> the MacPorts developers seem to believe that the cross-compilation
> rules don't apply in this situation and that they are free to leave
> configure using the default triplets for --host/--build/--target
> as i386-apple-darwin10 while setting the CFLAGS to -m64 behind configure's
> back. My reading of the line...

Cross-compilation "rules" don't apply because we aren't
cross-compiling. And, as I mentioned in my previous email, multiple
arch flags render the detected architecture irrelevant - we have to
work around the fact that configure scripts haven't adapted to modern
systems. This is why "fixing" config.guess really doesn't help
anything.

> Only booting the 64-bit kernel returns
> coherency to the situation with uname and arch reporting x86_64.

And I'll reiterate in case you still haven't figured it out... this is
*not* true.

- Toby