[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] OS X: make configure work better out of the box with FSF GCC

From: Daniel Colascione
Subject: Re: [PATCH] OS X: make configure work better out of the box with FSF GCC
Date: Mon, 28 Feb 2011 13:04:43 -0800

On Mon, Feb 28, 2011 at 11:56 AM, Glenn Morris <address@hidden> wrote:
> Daniel Colascione wrote:
>> I didn't include the corresponding configure changes; I figure I can let
>> whoever installs this patch regenerate the script.
> Could you explain what problem this change is supposed to fix?

Various header files (right now, Carbon --- which, granted, isn't used
in the in-tree Emacs) presume that Apple-gcc specific features like
printf attributes for CFStrings work.  With FSF gcc (i.e., gcc without
Apple-specific patches) these declarations break the build.  Defining
__INTEL_COMPILER essentially tells the system to use only the set of
gcc extensions supported by icc, which is a subset of the extensions
supported by FSF GCC.

>> +    case "$(which "${CC-cc}")" in
>> +      /usr/bin/* | /usr/lib/* )
>> +        CPP="${CC-cc} -E -no-cpp-precomp"
>> +        ;;
>> +      * )
>> +        # The below macro prevents the Carbon headers from defining
>> +        # nonstandard constructs not understood by FSF GCC.
>> +        CPP="${CC-cc} -E -D__INTEL_COMPILER=1"
> "FSF GCC" seems tautological at best.
> It seems fragile to test the location of the compiler. Why not test for
> the actual compiler version?

Apple essentially forked gcc 4.2, and it still reports that version.
I don't know a good way to distinguish Apple-patched gcc 4.2 from
FSF-issue gcc 4.2, and seeing whether the compiler is installed in the
"system compiler" location seems like a robust-enough way to figure
this out.  Another option would be to just do a test compilation, but
that takes time.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]