On Mon, Sep 14, 2009 at 14:03, Jack Howarth <[email protected]> wrote: > 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 >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > 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.
It's not the wrong answer. Where is uname documented as returning the default compiler output or exec behavior? That's a poor assumption that config.guess has relied on. It works fine in the archaic world of machines that can only run code compiled for a single architecture. Furthermore, most of these fixes do not require patching config.guess or passing --build, there are a number of different ways to solve the issue. - Toby _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
