Fwd: Interesting survey on Snow Leopard package managers

[Toby Peterson]

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
>> issue.
>>
>> - Toby
>
> 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.

- Toby