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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
