Description of problem: clang(++) reserves the word __block when you enable -fblocks support. Alas, unistd.h has (for a VERY long time) used this as the name of a variable, which causes clang to throw a fit: /usr/include/unistd.h:1147:35: error: __block attribute not allowed, only allowed on local variables extern void encrypt (char *__block, int __edflag) __THROW __nonnull ((1)); Version-Release number of selected component (if applicable): I have verified this issue in versions of glibc-headers from 2.12-1.107.el6_4.4 all the way to 2.16-34. It's an issue in all recent versions of Fedora and RHEL. How reproducible: This is 100% reproducible. Steps to Reproduce: 1. cat > /tmp/test.cpp <<EOF #include <unistd.h> EOF 2. clang++ -fblocks -c /tmp/test.cpp -o /tmp/test.o 3. Actual results: $ cat /tmp/test.cpp #include <unistd.h> $ clang++ -fblocks -c /tmp/test.cpp -o /tmp/test.o In file included from /tmp/test.cpp:1: /usr/include/unistd.h:1147:35: error: __block attribute not allowed, only allowed on local variables extern void encrypt (char *__block, int __edflag) __THROW __nonnull ((1)); ^ 1 error generated. $ clang++ --version clang version 3.3 (tags/RELEASE_33/rc2) Target: x86_64-redhat-linux-gnu Thread model: posix Expected results: clang++ -fblocks should work fine with all system headers. Additional info: You can fix the file by: sed -i -e 's/\*__block/\*__libc_block/g' /usr/include/unistd.h When you do this the compiler works just fine. If you want the one-line diff I can supply that to you.
Derek, This needs to go upstream immediately. It's a similar issue to what upstream has with __unused and BSD. Once upstream accepts it we can backport it. I fought to allow this kind of change in glibc, and I would champion this kind of patch for you (I'll do the review and check it in). Could you post your patch upstream on libc-alpha following the contribution checklist? Please CC me. https://sourceware.org/glibc/wiki/Contribution%20checklist Cheers, Carlos.
Note: The word __block can't be reserved, it's in the implementation namespace. However the implementations need to coordinate.
http://koji.fedoraproject.org/koji/taskinfo?taskID=5974585 commit a9c7f8acc7f553304a6d73fbee69b807f1c56fa6 Author: Carlos O'Donell <carlos> Date: Tue Sep 24 02:01:06 2013 -0400 Resolves: #1009623 - Avoid the use of __block which is a reserved keyword for clang++
(In reply to Carlos O'Donell from comment #3) Sorry, I was travelling. Does this update mean I don't need to send a patch to the upstream provider?
(In reply to Derek Atkins from comment #4) > (In reply to Carlos O'Donell from comment #3) > > Sorry, I was travelling. Does this update mean I don't need to send a patch > to the upstream provider? Sorry, yes, that's right. The glibc team will ensure that our rawhide patch goes upstream. It isn't fixed in f18, but it is fixed in rawhide and all fX releases going forward.
(In reply to Carlos O'Donell from comment #5) > > Sorry, yes, that's right. The glibc team will ensure that our rawhide patch > goes upstream. It isn't fixed in f18, but it is fixed in rawhide and all fX > releases going forward. Awesome! Any chance this fix can get pushed into EL6, too? Thanks!!!
(In reply to Derek Atkins from comment #6) > (In reply to Carlos O'Donell from comment #5) > > > > Sorry, yes, that's right. The glibc team will ensure that our rawhide patch > > goes upstream. It isn't fixed in f18, but it is fixed in rawhide and all fX > > releases going forward. > > Awesome! Any chance this fix can get pushed into EL6, too? > Thanks!!! No, sorry, at present we won't be pushing this fix into EL6.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This was fixed upstream in glibc 2.19, and is present in all supported Fedora releases.