On Wed, Sep 16, 2009 at 12:06:24AM -0500, Bob Friesenhahn wrote: > On Tue, 15 Sep 2009, Jack Howarth wrote: >> >> Rainer, >> Well taken. It really wasn't my idea to add that test. Ben wants to >> decouple from having a c compiler. I'll mention this issue. Still I >> think SL it will be a vast improvement if config.guess properly >> reflects the actual code generation and execution of the compiler. > > If the user configures using the 64-bit kernel but then decides to > reboot using the 32-bit kernel to run a video game, what happens in that > event? > > It seems to me that altering config.guess output based on whatever > kernel the system is using at that instant in time is fraught with peril > since it may be inconsistent over a period of time, possibly spanning > only minutes. Either the user should be provided with a way to specify > the type of code they want, or effort should be made to produce the > lowest common demominator by default. > > Bob > -- > Bob Friesenhahn > bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Bob, I am not proposing basing the config.guess results on what the kernel is but rather decoupling it from that. I misspoke earlier in that only 'uname -m' reports x86_64 on the x86_64 kernel under darwin10 (but that is orthogonal the problem since config.guess currently uses uname -p which is always i386 on both the 32-bit and 64-bit kernels. I am in fact suggesting the the config,guess result on darwin10 should be based on current code generation of the compiler as set on CC. Perhaps, I should clarify the situation on darwin10. It has the following behaviors... processor type non-EMT64 EMT64 -------------------------- kernel type 32-bit only 32-bit(default) 64-bit code execution 32-bit only 64-bit(default)/32-bit on both kernels code generation 32-bit 64-bit(default)/32-bit on both kernels command outputs uname -m i386 x86_64 uname -p i386 i386 arch i386 i386 Also note that gcc-4.2 is the default system compiler which executes/generates x86_64 code on EMT64 capable processors. The depreciated gcc-4.0 compiler still executes/generates i386 code on EMT64 capables processor (ie only the default system compiler, gcc-4.2, is built as native x86_64 code). I did file a radar report 6707283, arch command reports incorrect incorrect architecture without arguments). The darwin arch man page says... The arch command with no arguments, displays the machine's architecture type. The other use of the arch command it to run a selected architecture of a universal binary. A universal binary contains code that can run on different architectures. By default, the operating system will select the archi- tecture that most closely matches the processor type. This means that an intel architecture is selected on intel processors and a powerpc architecture is selected on powerpc processors. A 64-bit architecuture is pre- ferred over a 32-bit architecture on a 64-bit processor, while only 32-bit architectures can run on a 32-bit processor. which logically would suggest that arch without arguments should report the preferred architecture that will be used on that machine. My proposed patch is intended to test the code generation of CC and detect if __LP64__ is defined on the c compiler. So from the above, if you execute the following with the current config.guess, you will get (on EMT64 machines)... setenv CC gcc-4.2 ./config.guess i386-apple-darwin10 (even though the compiler is creating x86_64 code by default) The patched config.guess eliminates this error by testing if the generated code for CC as set is defining __LP64__. Thus you get... setenv CC gcc-4.2 ./config.guess x86_64-apple-darwin10 setenv CC "gcc-4.2 -m32" ./config.guess i386-apple-darwin10 setenv CC gcc-4.0 ./config.guess i386-apple-darwin10 setenv CC "gcc-4.2 -m64" ./config.guess x86_64-apple-darwin10 Ben Elliston also asked me to handle the case when the c compiler was unavailable. That part of that patch still needs work as we need to only perform that test on darwin >= 10 (since darwin9 could run x86_64 code but it is not the default architecture for code execution). Hopefully I was reasonably clear (it is a confusing situation). Jack _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
