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@xxxxxxxxxxxxxxxxxxx, 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 ;; _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
