Fwd: Interesting survey on Snow Leopard package managers

[Jack Howarth]

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.
                       Jack