request for configure clarifications on darwin10

Jack Howarth howarth at bromo.med.uc.edu
Wed Sep 16 06:01:45 PDT 2009


On Tue, Sep 15, 2009 at 11:52:35PM -0500, Bob Friesenhahn wrote:
> On Tue, 15 Sep 2009, Jack Howarth wrote:
>> 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.
>
> The notion of a "system compiler" seems immaterial to me since we are  
> not constrained to use it.  If the compiler produces default code which 
> does not run under the OS, that seems like a bug to me.
>
> Sun's Solaris supports both 32 and 64 bit kernels.  Under the 64 bit  
> kernel (and the 32-bit kernel), config.guess reports  
> "i386-pc-solaris2.10".  It is true that the freely downloadable compiler 
> from Sun does produce i386 type code by default.
>
> There is only so much you can expect from config.guess.  Except for  
> extraordinary cases, I would expect that config.guess output would be  
> based on output from 'uname'.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Bob,
   The question I have is, in such a case where the detected triplet from
config.guess reports a radically different architecture (i386-apple-darwin10)
than the actual default code execution and compiler code generation
(x86_64-apple-darwin10), might that not be considered a form of
cross-compilation requiring the user pass at least the --target triplet to
configure? Currently, many developers on darwin10 seem to be under the
impression that it is okay to leave configure believing the target is
i386-apple-darwin10 while the actual code generation is x86_64-apple-darwin10.
My view is that this is a misuse of configure since it is basically working
on incorrect assumptions about the architecture.
            Jack
ps I do believe config.guess should be patched. It seems bad form to leave
config.guess misreporting the architecture in this manner. The best approach
would seem to be decoupling the architecture from the kernel type and instead
relying on the actual code generation. I believe this is in fact done currently
for solaris in config.guess...

    i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
        eval $set_cc_for_build
        SUN_ARCH="i386"
        # If there is a compiler, see if it is configured for 64-bit objects.
        # Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
        # This test works for both compilers.
        if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
            if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \
                (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
                grep IS_64BIT_ARCH >/dev/null
            then
                SUN_ARCH="x86_64"
            fi
        fi
        echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
        exit ;;



More information about the macports-dev mailing list