Commit glibc-2.15-685-g5ac3ea1 introduced a regression: $ echo '#include <stdlib.h>' |gcc-4.1 -O2 -D_FORTIFY_SOURCE=2 -S -xc++ - -o/dev/null /usr/include/bits/stdlib.h:36: error: expected constructor, destructor, or type conversion before 'char' /usr/include/stdlib.h:972: error: expected `}' at end of input $ echo '#include <stdlib.h>' |gcc-4.1 -O2 -D_FORTIFY_SOURCE=2 -E -xc++ - |grep -A1 __extern_always_inline |head -2 __extern_always_inline __attribute__ ((__warn_unused_result__)) char * realpath (const char *__restrict __name, char *__restrict __resolved) throw () That is, g++ < 4.3 in fortify mode no longer compiles stdlib.h. The bug is somewhat similar to http://sourceware.org/bugzill/show_bug.cgi?id=13741 but is not exactly the same. There is one particular hunk of commit glibc-2.15-685-g5ac3ea1 that made the difference: -#if __USE_FORTIFY_LEVEL > 0 && defined __extern_always_inline +#if __USE_FORTIFY_LEVEL > 0 && defined __fortify_function Before that change, there were no attempts to include bits/stdlib.h in case of using old g++ in fortify mode, but there were another chances to hit undefined __extern_always_inline (the last is the subject of #13741). A proper definition of __extern_always_inline in sys/cdefs.h would fix both bugs.
Mine.
Should be fixed by b7bfe116.