request for configure clarifications on darwin10

[Jack Howarth]

On Wed, Sep 16, 2009 at 09:46:18AM -0400, Daniel J. Luke wrote:
> On Sep 16, 2009, at 9:01 AM, Jack Howarth wrote:
>> ps I do believe config.guess should be patched.
>
> sure, but that's an upstream issue.
>
>> It seems bad form to leave
>> config.guess misreporting the architecture in this manner.
>
> Do you have an example of a port (or class of ports) where this actually 
> causes a real problem?
>
> configure does lots of other stuff that's broken (testing for function  
> availability with link tests instead of using feature test macros,  
> inability to deal with multiple architecture builds in a sane way) - but 
> that doesn't mean MacPorts should be fixing (or attempting to fix that).
>
> --
> Daniel J. Luke
> +========================================================+
> | *---------------- dluke at geeklair.net ----------------* |
> | *-------------- http://www.geeklair.net -------------* |
> +========================================================+
> |   Opinions expressed are mine and do not necessarily   |
> |          reflect the opinions of my employer.          |
> +========================================================+
>
>

Daniel, 
    Well it may be an extreme case but the current Portfile
for gcc44 suffers from this problem since it passes -m64 on
the CFLAGS but doesn't correct the triplets that configure
is using...

http://trac.macports.org/ticket/20838

I fixed this easily by removing the passage of -m64 to
the CFLAGS and using the proposed config.guess patch to
return coherency to inputs configure is working with.

http://trac.macports.org/ticket/21341

Basically the breakage in the current packaging is that
FSF creates a 32-bit multilib on x86_64-apple-darwin10.
By not correcting the triplets and passing -m64 on the
CFLAGS, configure believes it is building a 32-bit
native compiler instead on i386-apple-darwin10 with
a 64-bit multilib. This totally blows up the logic
used in the FSF gcc build for the multilib of course.
    The most common case that I could imagine otherwise
would be software that uses configure to make either
settings to the Makefile for compiler flags or options
based on the detected target in use or more likely
cases when configure selects files of code with
hard coded assembly language that are architecture
dependent. We ran into a few of those in fink when
codecs, etc would have architecture specific assembly
files selected based on configure's understanding
of the exact architecture being built. 
                   Jack