configure.build_arch

[Anders F Björklund]

Jack Howarth wrote:

>     However config.guess upstream still needs to adapt to the new
> situation where the default architecture detected in darwin10 via  
> uname -p,
> for EMT64 capable hardware, diverges from that of the architecture of
> the code genererated by the default system compiler.

It just seems that the value of `uname -p` isn't useful for
determining the true architecture of the Mac operating system,
whether it's on "ppc-apple-darwin8" (that might run ppc64 too)
or "i686-apple-darwin10" (that might run x86_64 code as well)

And in fact, both Mac platforms are likely to be building more than
one arch whether it's ppc+i386 for Tiger or i386+x86_64 for Leopard.
So determining just one of them at ./configure time seems to be
rather limited - probably better off if done in the code instead ?

> My argument is that the current situation is already effectively
> a cross-compilation when the current config.guess is used on
> EMT64 capable hardware under darwin10. The architecture reported
> by config.guess is i386 so that configure believes it is working
> with and generating code for a 32-bit architecture whereas the
> compiler is silently generating 64-bit code behind configure's
> back. Not good in concept.
>              Jack

I just don't think that you can use the detected $build_cpu
for anything "useful" on the Mac OS X operating system...
Even if CVOG is "ppc-apple-darwin8" or "i686-apple-darwin10",
it might still be generating code for something else too ?

* CVOG = %{cpu}-%{vendor}-%{os}%{?gnu}, a.k.a. %{platform}

Sometimes it is useful to "pretend" to be cross-compiling
to another system, by passing --target and setting symlinks,
but for the general configure it's close enough with uname(1).
Sometimes it breaks, like for FSF GCC, but that's rare enough ?

> ps From my reading of...
>
> http://www.gnu.org/prep/standards/html_node/Configuration.html
>
> we actually should be passing --host=x86_64-apple-darwin10 -- 
> target=x86_64-apple-darwin10
> to configure...


For this to work in the same GNU-style, you would also need
a "x86_64-apple-darwin10-gcc" cross-compiler set up so that
you wouldn't have to pass the -m64 (or even -arch x86_64)
to get it to generate the proper code for the new --target.

I think you mentioned that you had done so with "wrappers"
in Fink, but it's not something that comes with the system ?
So I don't think that MacPorts will be changing either the
installed config.guess or the default --target parameters...

--anders