On Mon, Sep 14, 2009 at 14:16, Jack Howarth <[email protected]> wrote: > On Mon, Sep 14, 2009 at 02:07:51PM -0700, Toby Peterson wrote: >> 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 > > Toby, > You do realize that upstream will eventually fix this and an updated > config.guess will be pulled down from upstream to all of the projects > anyway. I don't see how you can say with a straight face that it is okay > for config.guess to report i386 when the default code generation and > execution of the default system compiler is in fact x86_64. As far as > configure goes...garbage in...garbage out. It has to be feed accurate > data from config.guess to make the appropriate decisions.
I don't think you're understanding me at all. If a project updates its config.guess and things work fine with the new output, that's fine. However, changing MacPorts base would have many unexpected effects that we'd be better off avoiding. Furthermore, I can say with a straight face that's it's ok for config.guess to return whatever it wants, because it usually makes no difference. It does for some ports, but not for most. - Toby _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
