configure.build_arch

[Jack Howarth]

On Wed, Sep 16, 2009 at 09:00:46AM +0200, Anders F Björklund wrote:
> Jack Howarth wrote:
>
>>    Reading through the commits on the configure.build_arch feature
>> in port, I am rather surprised that invoking that doesn't also
>> set the triplets for configure as well as passing the -m32 or
>> -m64 compiler flags. Wouldn't you at least want to set
>> --target= to the appropriate value so that configure understood
>> what architecture it was going to build for? I suppose such a
>> change might be an option to patching config.guess for those
>> Portfiles that use configure.build_arch. This would make sure
>> that configure was given --target=x86_64-apple-darwin9/10
>> when -m64 (or -arch x86_64?) was passed through the invoking
>> configure.build_arch.
>
> We set the triplets back when we were (ab)using +universal
> to do cross-compilation, with the three universal_ flags:
>
> http://lists.macosforge.org/pipermail/macports-dev/2008-February/ 
> 004358.html
>
> It never worked very well, so in MacPorts 1.8.0 it was all
> ripped out in favor of the much simpler build_arch solution...
>
> --anders

Anders,
   My main concern is that the autoconf folks fully understand
all of the details of darwin10 so that whatever change created
upstream is as well thought out as possible.
   I still think that anytime port (on at least darwin10) is
passing -m64 or -arch x86_64 to configure, via build_arch, that
we should at least pass --target=x86_64. Currently to configure,
darwin10 acts effectively like a cross-compiler in that the detected triplet
for --host is i386-apple-darwin10 but the actual code generation
is x86_64-apple-darwin10. Simply making sure that the --target
is set by build_arch, so that configure properly understands that actual
code generation being used, should help a lot.
           Jack
ps We are starting to get reponses on autoconf mailing list so hopefully
they cant arrive at a consensus on whether we should pass --target on
darwin10 with the existing config.guess. I would note that Ben
Elliston, the config.guess maintainer, is already on board with
the concept of decoupling the output of config.guess from the
kernel and instead on the code generation of the c compiler
as defined by CC.