Description of problem: Just trying out clang++. Doesn't seem to be useful on f17. Just include <complex> gives: In file included from .sconf_temp/conftest_0.cpp:2: In file included from /usr/include/eigen3/Eigen/Core:149: In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/complex:46: In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/sstream:38: In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/istream:39: In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42: In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40: /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45: error: use of undeclared identifier '__ATOMIC_ACQ_REL' { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); } ^ /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38: error: use of undeclared identifier '__ATOMIC_ACQ_REL' { __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); } ^ In file included from .sconf_temp/conftest_0.cpp:2: In file included from /usr/include/eigen3/Eigen/Core:155: /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1404:27: error: use of undeclared identifier '__int128'; did you mean '__int128_t'? struct numeric_limits<__int128> ^ /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:36: error: expected '>' struct numeric_limits<unsigned __int128> ^ /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:5: error: cannot combine with previous '(error)' declaration specifier struct numeric_limits<unsigned __int128> ^ /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:44: error: expected unqualified-id struct numeric_limits<unsigned __int128> ^ 6 errors generated. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Neil, This is a known problem -- upstream fixed it rather late in the 3.1 development series, so it's not straightforward to backport the fix to the 3.0 we ship in Fedora 17. I'm working on packaging LLVM/Clang 3.1 for Rawhide -- will try and sort out some of the directory layout issues at the same time. I'll ask around on the mailing list if we can push this to the stable branches too, if the key packages depending on LLVM (e.g. mesa) builds fine with 3.1.
I get the same issue. Seems that every C++ program using the STL cannot compile. This makes clang for C++ totally useless. can a user decide to move to clang 3.1, even if Fedora does not want to upgrade clang during a release? On my machine llvm & clang do not trigger any extra dependency, so it should be pretty riskless.
OK, I should have checked more. Here, llvm-libs-3.0 is only required by mesa-dri-drivers. Would it make sense to take them both from Rawhide? Or I go in an endless loop?
I think this really needs to be fixed, either by backporting the fix(es) or by just upgrading LLVM.
This bug is a duplicate of this one: https://bugzilla.redhat.com/show_bug.cgi?id=845713 Please resolve it, I don't have sufficient privileges.
*** This bug has been marked as a duplicate of bug 845713 ***