llvm-3.4.16 and newer does not build with glibc-2.19.90-32.fc21 installed. The issue is related to the __extern_always_inline is no longer available when the compiler identifies itself as GCC 4.2 or older. llvm/clang-3.4.16 needs this macro and identifies itself as GCC 4.2. Propsal: Allow #ifdef __clang__ to qualify for enabling the __extern_always_inline macro in sys/cdefs.h.
A patch with the suggestion: --- include/sys/cdefs.h 2014-08-25 11:37:25.980027701 +0000 +++ include/sys/cdefs.h-proposal 2014-08-25 11:37:07.070028122 +0000 @@ -319,7 +319,7 @@ /* GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99 inline semantics, unless -fgnu89-inline is used. */ -#if !defined __cplusplus || __GNUC_PREREQ (4,3) +#if !defined __cplusplus || __GNUC_PREREQ (4,3) || defined __clang__ # if defined __GNUC_STDC_INLINE__ || defined __cplusplus # define __extern_inline extern __inline __attribute__ ((__gnu_inline__)) # define __extern_always_inline \
What does it need the macro for? That macro is only optionally defined, so all uses of it should be guarded. Your patch doesn't look right to me, do all clang versions support the __gnu_inline__ attribute in C++? As it has been only introduced in GCC 4.3, it is unclear if clang had that support from the very first release.
According to the earlier clang patch that we had accepted upstream (and then later reverted along with earlier patches in recently in Fedora), all clang versions that support __gnu_inline__ attribute export either __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__. The conditional in comment 1 is wrong, but maybe we could add another (untested) snippet: #if !defined __extern_always_inline && defined __clang__ # if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__ # define __extern_inline extern __inline __attribute__ ((__gnu_inline__)) # define __extern_always_inline \ extern __always_inline __attribute__ ((__gnu_inline__)) # else # define __extern_inline extern __inline # define __extern_always_inline extern __always_inline # endif #endif This ought to ensure that the gcc use case is unchanged and the clang use case remains as it was before.
I've posted a candidate patch upstream: https://sourceware.org/ml/libc-alpha/2014-09/msg00375.html
Pushed build. Please verify once it is done and post results. http://koji.fedoraproject.org/koji/taskinfo?taskID=7593210
David confirmed offline that the patch helps build llvm successfully, so closing this bug with a build in f21 and f22. Please reopen if you find and issues.
glibc-2.20-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/glibc-2.20-2.fc21
glibc-2.20-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/glibc-2.20-3.fc21
glibc-2.20-3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1133301 has been marked as a duplicate of this bug. ***