request for configure clarifications on darwin10

[Jack Howarth]

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

The target type normally defaults to the host type. Programs for which 
cross-operation is not meaningful need not accept the ‘--target’ option, 
because configuring an entire operating system for cross-operation is not a 
meaningful operation.

at http://www.gnu.org/prep/standards/html_node/Configuration.html seems to 
differ
from their's. I would argue that since darwin10 is a hybrid OS where the 
reported
architecture from uname -p and uname -m is always i386 (when the 32-bit kernel 
is used)
that this rule doesn't apply since the compiler is in fact executing and 
generating
x86_64 code and thus the actual host and target aren't identcal (at least with 
the current config.guess).
   Am I correct to say that it is wrong to change the architecture of code 
generated with
CFLAGS to x86_64 when configure is not being given 
--target=x86_64-apple-darwin10? I would
have thought not passing --target would be a bad thing since configure will 
believe it
operating with --host/--build/--target defaulted to the i386-apple-darwin10 as 
reported by
config.guess while the compiler is in fact generating x86_64. Am I correct in 
saying that
in such a case, --target=x86_64-apple-darwin10 must be passed (unless a patched 
config.guess
is used to base the reported architecture on the default compiler code 
execution/generation
and not the kernel architecture)? Thanks in advance for any clarifications on 
this issue
which is causing much confusion for darwin10 developers.
            Jack
ps Isn't darwin10 the very first hybrid OS which the configure machinary has 
been
faced with? I am unaware of any other operating systems that ever differed the
architecture of the kernel and the default code execution/generation of the
default system compiler. Unfortunately both uname and arch will report i386 on
darwin10 on EMT64 capable hardware. Only booting the 64-bit kernel returns
coherency to the situation with uname and arch reporting x86_64.