configure.build_arch

Toby Peterson toby at macports.org
Tue Sep 15 16:01:43 PDT 2009


On Tue, Sep 15, 2009 at 15:43, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Tue, Sep 15, 2009 at 02:43:29PM -0700, Toby Peterson wrote:
>> On Tue, Sep 15, 2009 at 14:23, Jack Howarth <howarth at bromo.med.uc.edu> 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.
>>
>> It does pass -m32/-m64 if the configure.compiler setting refers to a
>> compiler that doesn't support -arch 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?
>>
>> Passing --target doesn't make any sense, as we are not cross-compiling.
>>
>> - Toby
>
> The last statement would be true if the current config.guess weren't
> reporting the wrong architecture on EMT64-capable processors on 10.6.
> I assume invoking...
>
> configure.build_arch x86_64
>
> sets the CFLAGS to -m64, right. So here we have the same issue all over
> again. The configure execution reports back i386-apple-darwin10 (even
> though the compiler is now generating code with -m64). Configure makes
> decisions based on its understanding that the target architecture is
> actually 32-bit while the compiler actually is generating 64-bit code behind
> its back. This isn't rocket science. You can't go around changing the
> code generation behind configure's back like this. Consider the text
> at...
>
> http://www.gnu.org/prep/standards/html_node/Configuration.html
>
> which states...
>
> The target type normally defaults to the host type. Programs for which cross-operation is not meaningful need not accept the ‘--target’ option, because configuring an entire operating system for cross-operation is not a meaningful operation.
>
> Now what you say would normally be true but as 10.6 is a hybrid OS so
> the first clause is NOT true. The target type for -m64 code (x86_64-apple-darwin10)
> is not the same as the *reported* host type (i386-apple-darwin10). You
> have to consider that configure is free to make decisions about setting up the
> Makefiles based on its understanding (without additional options like
> --target=) that the host type (i386-apple-darwin10) is the operative
> target (which it isn't when the compiler is generating x86_64 code).
>  I guess I can go upstream and try to find one of the maintainers of autoconf
> to provide an authorative clarification from upstream for the group here.

For the few ports that actually care, only --build makes any sense. We
don't support cross-compiling, and very few configure scripts get it
right anyway.

Anyway, the current approach is mostly designed around keeping things
working in the future. Universal building currently configures with
multiple -arch flags set, and this is not going to change. The main
consequences of this are that configure's detected architecture is
fairly irrelevant, and that we have to work around configure results
anyway. Not much we can do about this, configure just isn't
well-suited to deal with the modern problems of multiple
architectures, SDKs, etc.

In other words, feel free to hack the ports as needed - just keep in
mind that "fixing" config.guess is hardly a perfect solution
(especially for universal building), and that MacPorts base is not
going to be passing these flags to configure.

- Toby


More information about the macports-dev mailing list