clang defines __weak as if -fobjc-gc were specified

This is with a clang built from trunk head yesterday.

When clang is run without objc-gc mode,
clang defines the symbol __weak as if -fobjc-gc were specified.
clang defines the symbol __strong as empty.

Here are two commands, the first shows the clang symbols,
the second shows the warning when a source file wants to define
__strong and __weak itself.

$ echo | clang -E - -dM | egrep “strong|weak”

#define __strong
#define __weak attribute((objc_gc(weak)))

$ clang -E - <<EOF
#define __strong
#define __weak
:2:9: warning: ‘__weak’ macro redefined
#define __weak
:158:9: note: previous definition is here
#define __weak attribute((objc_gc(weak)))

1 warning generated.

Yes, this is what we've always done on Darwin. Is there a problem specifically?


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 ?

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 . (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.


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.


I thought I sent out this email earlier. But here it is again.

__weak is always defined for use in blocks. It is unfortunate though that it is def’ed to
objc_gc(weak) though. But for the purpose of use, it doesn’t really matter.

  • Fariborz