Description of problem: clang++ cannot compile a hello world program in Fedora 17 Version-Release number of selected component (if applicable): clang version 3.0 (tags/RELEASE_30/final) How reproducible: make a hello world program in C++ and try compile with clang++ see here also: http://ask.fedoraproject.org/question/2193/clang-not-working-in-fedora-17 Steps to Reproduce: 1. sudo yum install clang 2. write a hellworld.cpp 3. compile: `clang++ helloworld.cpp` Actual results: output: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iostream:39: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40: /usr/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); } ^ /usr/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' Expected results: a executable a.out that prints 'hello world' when executed. Additional info: clang++ works well in Ubuntu 12.04
ClanLib is a gaming library :) http://clanlib.org/wiki/Main_Page clang is part of llvm, changing component.
The problem is not with clang, but with the gcc libraries. Solution is to use libc++, not libstdc++. It would be greatly helpful if someone were willing to package: http://libcxx.llvm.org/
The problem is that clang 3.0 does not support atomic operations, so it can't compile anything that needs libstdc++. Of course, one solution is to use libc++, however, this will make it impossible to link against packages compiled with gcc (all Fedora-supplied packages, actually). The only real fix is to upgrade llvm package to version 3.1, which includes support for atomic operations and works with gcc libstdc++. Fedora Rawhide already has working llvm 3.1 packages, is it possible to backport this to Fedora 17? If not, then this bug should be closed as WONTFIX, because there isn't really any other proper solution that applies.
-1 to WONTFIX. What's the point of packaging a program that does not work. This is exactly what WONTFIX will do. +1 to packaging libc++. and +2 to updating to llvm 3.1.
Is it possible to backport the support for atomic operations from 3.1 to 3.0? If not, upgrading to 3.1 is the only way forward.
> Is it possible to backport the support for atomic operations from 3.1 to 3.0? No, unfortunately, it is not.
see https://bugs.archlinux.org/task/29397 why would that fix not work here? Fedora's `bleeding edge` is not bleeding enough to get openCL working. I support the comments in comment #4.
The "fix" in Arch Linux was just that the user compiled clang-svn, i.e. the latest version from SVN, i.e. upgrading to 3.1 or something even newer. It's not a backport. But IMHO backporting is always possible, it just takes someone to look into it. Of course, it might not be worth the effort, upgrading might be the better solution. But it's just unacceptable that this is not resolved now, months after the F17 release!
Ah, OK. I guess I don't really care, just as long as stuff really works. And from this bug I gather that it doesn't. Although I think I prefer the upgrade to 3.1 or better...
There seems to be a very tight interdependence between the version of libstdc++ and clang. Upgrading clang to maintain this delicate balance is really a nightmare. This same issue will occur in the future once libstdc++ is updated, and we will once again have broken systems until clang devels make a new release that once again restores compatibility, and that release gets included as an update to Fedora. It seems to me that the most sensible route to take is to package libc++, and not depend on this delicate (and, in my opinion, fundamentally broken) balance.
Hi Alex, > There seems to be a very tight interdependence between the version > of libstdc++ and clang. Upgrading clang to maintain this delicate balance > is really a nightmare. I think you are overly dramatizing the problem. Atomics is a new feature of C++ and gcc gained the support for it very early on. It was added to Clang a bit later, but late enough for clang 3.0 package to make into Fedora, instead of newly released clang 3.1, whereas gcc was upgraded to 4.7 before any other distribution. Obviously, the user community of clang in Fedora is still quite small and not enough importance is attached to keeping clang working properly, otherwise, clang 3.1 would have made it into updates long time ago. The solution to the problem is very straightforward and doesn't require much work, it's just that there is not enough interest for this to happen... Now having this said, I don't expect for such problems to re-occur anytime soon (maybe until the next major revision of the C++ standard), and both gcc and clang are adding the support for the latest features very quickly. So I don't really see much reason for panicking, let's just get clang upgraded to 3.1 and get over it. Z.
The problem is that this is not the first time clang is broken in Fedora due to an issue like this. But I don't think using libc++ is an acceptable solution either, as it'd mean clang binaries would be binary-incompatible with g++ binaries (due to symbol conflicts between the C++ runtimes) and thus also with all the system libraries in Fedora.
> But I don't think using libc++ is an acceptable solution either I also think that adding a new runtime is more complicated than just packaging it so that clang can use it. I would be interested in having switchable runtimes, but not sure whether it's even possible to achieve binary compatibility on this level...
(In reply to comment #8) > But IMHO backporting is always possible, it just takes someone to look into > it. Of course, it might not be worth the effort, upgrading might be the > better solution. But it's just unacceptable that this is not resolved now, > months after the F17 release! "unacceptable" is a bit strong. Fact is, not enough people are interested in maintaining LLVM / clang - I've asked on the development list for help maintaining this package in the past, and nobody stepped up. Normally, I'd just upgrade LLVM to 3.1, but unfortunately now that it's used to compile Mesa's llvmpipe LLVM is too critical for such a major update. So it's caught between two worlds -- critical enough to not be updated, but not critical enough that GCC and libstdc++ updates take place without considering whether clang++ gets broken. I've been tempted to just disable clang's C++ support completely until the situation is resolved, actually.
Hi Michel, I happened to miss the llvmpipe part of the story, thanks for explaining the situation. I would suggest to leave things as is then, since clang 3.1 is going to make it into Fedora 18 anyways, right? Not sure if it's possible to issue erratas for Fedora, if yes, then maybe one can be issued stating that in this particular version clang doesn't work with anything that requires standard C++ library to compile... Z.
LLVM/clang 3.1 has been in Fedora 18 / Rawhide since shortly after their release, yes. There are two other options, short of backporting, though both involve quite a bit of work as well: * create a compatibility version of g++/libstdc++, to be used by clang. For every Fedora release, synchronize this compatibility version with the latest version of mainline g++/libstdc++ that can build that version of clang. Not sure the GCC maintainers would like this approach though * have two LLVM packages -- the "core" one to be used for critical components like LLVM, and comes without Clang. The "full" LLVM package ships with clang and gets updated whenever upstream releases a new version. Problem with option #2: what to do when both are at the same version?
I really don't see why we can't just issue an update of llvm with a rebuild of affected packages including mesa. Chickening out just because mesa is critpath is not an acceptable way to look at things. 3.1 has been released as stable by upstream and it's working fine for F18, so why not push it out to F17 too, as it's needed to fix things?
And I think having 2 versions of LLVM is a horrible solution, we've had our share of symbol conflicts between llvmpipe and OpenGTL already, back when LLVM was statically linked (it didn't even have to be a different version for it to be a mess), so one shared and up-to-date LLVM is really what we need. I don't see why we need to version-lock LLVM on an old buggy version just because it's in the critical path.
The relevant commit for a backport appears to be: http://llvm.org/viewvc/llvm-project?view=rev&revision=154640 Some followups may be useful (or even needed) though.
And at least those 2 are needed first (154640 builds on them): http://llvm.org/viewvc/llvm-project?view=rev&revision=154513 http://llvm.org/viewvc/llvm-project?view=rev&revision=154579
I agree with Kevin, having two llvm packages is going to be a nightmare. Patched libstdc++ is absolutely a no-go too, since this doesn't guarantee that software linked against it can also link against software linked with unpatched libstdc++, so it doesn't really help, one might just as well package libc++ and use it instead... I would suggest either a backport + rebuild as Kevin proposed, or if there isn't enough manpower, just leave it as is, since it's gonna be fixed in FC18 anyways.
Fair enough, I'll do a backport, and ask everyone involved to test. Are any of you provenpackagers? I've never needed to use LLVMpipe for my own machines myself, so presumably a way to test this properly is to boot F17 in KVM.
Hi Michel, Unfortunately, I'm not a provenpackager, but I can test your llvm backport on my headless builders if this helps. As for LLVMpipe, I believe you are correct. Z.
*** Bug 824406 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
There won't be an llvm update for F17 at this point in its life, F19's about to release so it doesn't have much time left anyway. hello-world c++ apps work for me with llvm 3.3 in F18 and up though, closing.