Removing autoconf from cc for this reply... On Tue, Sep 15, 2009 at 16:20, Jack Howarth <[email protected]> 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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
