On Mon, Sep 14, 2009 at 10:21:42PM +0200, vincent habchi wrote: > Le 14 sept. 2009 à 22:15, Daniel J. Luke a écrit : > >> On Sep 14, 2009, at 4:08 PM, 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? >> >> No, but it's probably possible to get configure to correctly build a >> triple by using other tools (like it has to do on solaris, for >> example). >> >> It sounds like that's what Jack has done with his updated >> configure.guess... >> >> I would tend to agree with Toby, though, that this probably isn't >> something that needs to be addressed by base/ > > Could it also be reported as a bug to Apple, to be modified in a future > SL patch? After all, if I read the manpage correctly, uname -p is > supposed to reflect the processor architecture, which is not the > architecture the kernel was build for. > > V. > _______________________________________________ > macports-dev mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
These have been reported to Apple as radar 6707283, "arch command reports incorrect architecture without arguments", and radar 6407447 ,"uname -p, uname -m and uname -a give inaccurate results in Snow Leopard". Apple is not going to change this from their side as they view as misuse of uname by config.guess (hence the patch). Take a look at http://savannah.gnu.org/patch/?6827 where this issue was first reported. Also note that this problem disappears when you are running Snow Leopard under the 64-bit kernel. Apple wants to tether uname -p and uname -m to the code execution of the kernel and not the executables (for whatever reason) and that won't change. Jack 6707283 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
