Bug 845713 - clang++ cannot compile a hello world program
clang++ cannot compile a hello world program
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: llvm (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Reopened
: 824406 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-03 22:41 EDT by alfredo.correa
Modified: 2013-06-26 13:53 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-26 13:53:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description alfredo.correa 2012-08-03 22:41:17 EDT
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
Comment 1 Hans de Goede 2012-08-04 04:55:44 EDT
ClanLib is a gaming library :)
http://clanlib.org/wiki/Main_Page

clang is part of llvm, changing component.
Comment 2 Alex G. 2012-08-13 02:17:17 EDT
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/
Comment 3 Yury V. Zaytsev 2012-08-19 16:40:54 EDT
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.
Comment 4 Alex G. 2012-08-20 14:21:47 EDT
-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.
Comment 5 Kevin Kofler 2012-09-03 13:42:14 EDT
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.
Comment 6 Yury V. Zaytsev 2012-09-03 13:44:43 EDT
> Is it possible to backport the support for atomic operations from 3.1 to 3.0?

No, unfortunately, it is not.
Comment 7 udo 2012-11-04 03:27:17 EST
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.
Comment 8 Kevin Kofler 2012-11-04 10:04:19 EST
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!
Comment 9 udo 2012-11-04 10:22:42 EST
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...
Comment 10 Alex G. 2012-11-04 10:52:54 EST
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.
Comment 11 Yury V. Zaytsev 2012-11-04 12:08:03 EST
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.
Comment 12 Kevin Kofler 2012-11-04 13:14:41 EST
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.
Comment 13 Yury V. Zaytsev 2012-11-04 13:54:59 EST
> 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...
Comment 14 Michel Alexandre Salim 2012-11-04 22:35:28 EST
(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.
Comment 15 Yury V. Zaytsev 2012-11-05 02:54:06 EST
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.
Comment 16 Michel Alexandre Salim 2012-11-05 06:04:54 EST
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?
Comment 17 Kevin Kofler 2012-11-05 11:10:15 EST
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?
Comment 18 Kevin Kofler 2012-11-05 11:12:42 EST
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.
Comment 19 Kevin Kofler 2012-11-05 11:23:46 EST
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.
Comment 20 Kevin Kofler 2012-11-05 11:26:41 EST
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
Comment 21 Yury V. Zaytsev 2012-11-05 16:48:43 EST
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.
Comment 22 Michel Alexandre Salim 2012-11-16 03:56:24 EST
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.
Comment 23 Yury V. Zaytsev 2012-11-16 03:59:07 EST
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.
Comment 24 Kevin Kofler 2013-01-23 19:33:23 EST
*** Bug 824406 has been marked as a duplicate of this bug. ***
Comment 25 Fedora Admin XMLRPC Client 2013-02-27 10:11:44 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 26 Adam Jackson 2013-06-26 13:53:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.