Fwd: Interesting survey on Snow Leopard package managers
howarth at bromo.med.uc.edu
Mon Sep 14 14:03:40 PDT 2009
On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote:
> On 2009-9-15 06:08, vincent habchi wrote:
> >> K64 makes no difference - config.guess uses uname -p, which is i386 on
> >> K32 and K64. The fact is that arch/uname aren't the correct tools for
> >> determing the answer to this particular question.
> > Granted that point, is it possible to build, or provide, a modified
> > version of uname, to be put in the tools or whatever suitable directory,
> > and that would override /usr/bin/uname with more sensible data? Does it
> > make sense?
> On a universal i386/x86_64 system, i386 is *a* correct answer for uname
> -p to be giving...
> - Josh
> macports-dev mailing list
> macports-dev at lists.macosforge.org
Actually it is the wrong answer because i386 is NOT the default code
execution (unless you are on Core Solo or Core Duo). This whole issue
is rather unfortunate in that Apple is the first vendor to ever
deliver a hybrid OS that runs a 32-bit kernel but 64-bit executables.
Apple decided to tether uname -m and uname -p to the kernel code
execution (hence this problem goes away when running the 64-bit kernel).
The whole point of the config.guess patch make sure that the reported architecture
accurately reflects the native code execution and generation of the system compiler
in Snow Leopard which is always x86_64 on EMT64 capable hardware. Again
you really only have two valid solutions. Patching config.guess or
explicitly correcting the triplets to x86_64 on the configure arguments.
More information about the macports-dev