Thu 20 Oct 2011 09:02:56 AM UTC, comment #2:
This looks like a clang bug.
As far as I can tell ... the state of affairs is as follows.
1. glibc in one of it's headers used __block as an identifier. They chose that because by convention the underscore prefix is reserved for the system (stuff like libc, other core system headers, the compiler etc) and it wasn't in use by any other software, but while legitimate, they could have made better choices.
2. then Apple chose __block as a type qualifier for their addition of blocks to the programming language ... I guess they didn't check to see if it was already in use (or only checked about OSX). I hate the use of underscores here as it's totally inconsistent with other type qualifiers in C/ObjC, but we're probably stuck with it.
3. we try to work around the conflict by redefining the __block in the preprocessor before including the system headers and undefining that again afterwards. But then find that clang has defined __block, so we have to undefine it, redefine it, and then undefine it again.
Thus far I'm sure of the facts ... the next is inference:
4. Now it looks like clang doesn't support __block as a proper qualifier/reserved word, so our workaround has trashed clang's preprocessor definition, and clang then doesn't know how to deal with __block when it appears in the code used as a type qualifier.
I'd guess we could do some sort of test to see what clang defines __block to be, and redefine it to that in gnustep-base after having included the system headers ... but that sounds like a very fragile hack ... probably it would be betterto see if the clang developers can fix things somehow.
|