Fwd: Interesting survey on Snow Leopard package managers
toby at macports.org
Mon Sep 14 14:07:51 PDT 2009
On Mon, Sep 14, 2009 at 14:03, Jack Howarth <howarth at bromo.med.uc.edu> 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
>> 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.
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
More information about the macports-dev