request for configure clarifications on darwin10

[Jack Howarth]

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 at simple.dallas.tx.us, 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