Interesting survey on Snow Leopard package managers

Jack Howarth howarth at bromo.med.uc.edu
Mon Sep 14 15:33:20 PDT 2009


On Mon, Sep 14, 2009 at 05:28:32PM -0400, Jeremy Lavergne wrote:
>> 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.
>
> It sounds like the change does nothing more than allow for 64bit to be  
> built correctly on the 32bit kernel of SL.
>
> Is that a good summary for what's going on?
>
> Also, Jack, do you have time to meet sometime?  I'm over at CCHMC  
> usually and would like to get a better understanding if I'm not  
> reflecting it in the above summary :-)

Jeremy,
    What the config.guess patch does is decouple its output from the
architecture of running kernel and depend instead on the code generation
of the system compiler. My own theory on why Apple didn't make any
changes to the output of uname or arch was that they were afraid some
third party installers or scripts might be depending on the i386
and that would cause more breakage on Snow Leopard. In conversations
with Mike Stump in Apple compiler group, he did come around to my
view that a careful reading of the "arch" manpage shows that command
should really reflect the default code execution on Snow Leopard.
However none of this will change, so config.guess will have to adapt
to a hybrid 32-bit kernel/64-bit userland which it never was faced
with before. The problem with leaving the architecture reported as
i386 on Snow Leopard is that configure while make changes to the
generated Makefiles using the assumption at it dealing with 32-bit
code generation. In a perfect world, this wouldn't be a problem
and everyone would be coding with __LP64__ wrappers instead of using
configure to make decisions like that but thats not always the case.
            Jack



More information about the macports-dev mailing list