Interesting survey on Snow Leopard package managers

[Jack Howarth]

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
> macports-dev at lists.macosforge.org
> 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