[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.
>> + CPPFLAGS="$CPPFLAGS -D__INTEL_COMPILER=1"
>> + 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.