Hi Charles, thanks for replying!

Yes, that is what I saw as well. The question is which compiler is used (by
default) when building Emacs on 10.6. I guess it is "gcc", but I didn't
have time to verify this.

    -- Anders

On Mon, Jul 17, 2017 at 10:09 PM, Charles A. Roelli <charles@aurox.ch>
wrote:

> clang and gcc seem different on 10.6 (can't say for certain, though):
>
>
> $ which gcc
> /usr/bin/gcc
> $ gcc --version
> i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
> 5658) (LLVM build 2335.15.00)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ which clang
> /usr/bin/clang
> $ clang --version
> Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
> Target: x86_64-apple-darwin10.8.0
> Thread model: posix
>
>
>
>
>
> On 17/07/2017 01:01, Alan Third wrote:
>
>> On Sun, Jul 16, 2017 at 08:43:25PM +0200, Anders Lindgren wrote:
>>
>>> I tried to figure out if gcc or clang was used when building on 10.6.8,
>>> but
>>> ran out of time (and won't have the chance to do it again anytime soon).
>>> I
>>> did conclude that it comes with both a real "gcc" and a real "clang", so
>>> presumably gcc is used. (Surprisingly, more modern versions of macOS
>>> seems
>>> to map the command "gcc" to "clang".)
>>>
>> Charles can maybe answer this for us, as he uses 10.6.
>>
>> A warning-free build is a must on modern system (which use clang). It
>>> would
>>> be nice on older system, I guess, but it would be hard to enforce. (We
>>> could even lobby to add the option to future gcc versions, for the
>>> benefit
>>> of GNUStep, but it would not help the situation on older macOS versions.)
>>> My gut feeling is to go with the NS_SILENCE_MISSING_METHOD_WARNING_BEGIN
>>> solution, as it work on modern macOS systems, it retains type checking,
>>> and
>>> it give us a single location to describe the situation and to modify the
>>> macro, if there should be a need for it in the future.
>>>
>> Agreed.
>>
>> I think that a lot (if not most) of the code that we might want to use
>> this on won’t work on GNUstep at all, so we could still exclude it
>> from building there if the warnings are too much.
>>
>>
>