patching config.guess or passing triplets

[Jack Howarth]

On Sun, Sep 13, 2009 at 03:24:24AM -0500, Ryan Schmidt wrote:
> Jack,
>
> Thank you for your willingness to help us fix things. I think you have a 
> much greater knowledge of compilers than I do, because a lot of your  
> comments are going right over my head. Is there a specific change you're 
> recommending we make in MacPorts base, such as always passing --host, 
> --build and/or --target to ./configure? Or a specific thing maintainers 
> of all ports should be watching out for?

Ryan,
   I am going to write an email to this later today explaining my
understanding of the approach and compiler wrapper infrastructure
being used for i386 fink on 10.6 and x86_64 fink on 10.5 as well
as the requirements this imposes on the packaging used. Fink 
actually came to regret having tried to implement i386 fink on
10.6 but was so far along there was no point to junking it.
   If you really want to support the option of having MacPorts
build i386 packages on 10.6 (when the compiler default is really
x86_64 code), the only rational approach is to resort to compiler
wrappers that effectively sneak -m32 into the compiler commands.
I would strongly suggest it isn't really worth the effort and it
would be much smarter to just leverage the proposed config.guess
change to eliminate the problem in Snow Leopard where the triplet
is incorrectly reported and configure misjudges the default code
generation. In fink, I don't think considered this option in part
because we started out with the idea of i386 fink on 10.6 where
that wouldn't have helped at all. If you patch config.guess to
properly report x86_64-apple-darwin10, on EMT64-capable processors
there is no need to manually pass the triplet on --host/--build/--target
to configure. Config.guess will give configure that answer correctly
on its own. You will want to go through the MacPorts packages and,
when you patch config.guess, revert any attempts to manually
pass -m64 on the compiler flags as those will be unnecessary and
may actually confuse the build process (as was the case with the
multilib in gcc44...although that is a pretty unique issue).
                 Jack
ps I spent several hundred hours testing i386 and x86_64 fink on
10.6 as well as x86_64 fink on 10.5 during the past year and
making x86_64 package variants for x86_64 fink on 10.5/10.6.