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