[cfe-dev] clang defines __weak as if -fobjc-gc were specified

[Frank Rehwinkel]

Totally agree.  But I'm just coming to the GNUstep project.    And while it
used to be supported for Darwin - before clang was an option, it seems an
unsupported platform option these days - ironic really.  So I'm a little
bit on my own on this one and just trying to make it compile with the
minimum of changes to see if it will even work again.

Just had another look at the code.  Maybe __strong and __weak can be
undef'ed when the platform is Darwin/clang.

For that matter, now I' curious what is different about this build on
FreeBSD, where GNUstep is actively maintained and clang is used.  I know
they wouldn't have left these warnings as part of their build.

Thanks.


On Wed, Jun 5, 2013 at 1:09 PM, John McCall <rjmccall at apple.com> wrote:

> On Jun 5, 2013, at 10:06 AM, John McCall <rjmccall at apple.com> wrote:
>
> On Jun 5, 2013, at 10:04 AM, Frank Rehwinkel <frankrehwinkel at gmail.com>
> wrote:
>
> Thanks for asking.  I just want to make sure I understand your statement
> and question.  On Darwin, you've always had __weak defined as __attribute__((objc_gc(weak))),
> even when __strong is defined as <empty>?
>
> If it is intentional, then I would say there is no specific problem.  We
> can put a comment into the header file for GNUstep to explain why __weak is
> being undef'ed before it is defined as <empty>.  (Without the undef, the
> build generates seemingly hundreds of warnings, obscuring other warnings
> that might be more meaningful.)
>
> If it is unintentional, then a change to clang would obviate the
> additional code in the GNUstep header and save a few seconds every time
> someone went to read through the logic of those __strong and __weak macro
> definitions.
>
>
> Why don't you just not #define __weak and __strong on Darwin?
>
>
> Or, for that matter, if they're already defined?
>
> Headers that randomly change macro state are somewhat evil;  among other
> things, they tend to introduce nasty order-of-inclusion bugs.
>
> John.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130605/542cb852/attachment.html>