|Summary:||Update the llvm version to 3.5|
|Product:||[Fedora] Fedora||Reporter:||Michael Wolf <mjwolf>|
|Component:||llvm||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||21||CC:||agrover, ajax, avi.kivity, bos, dan, davids, dmalcolm, gustavold, hannsj_uhl, jv+fedora, kajtzu, maxim.prohorenko, ndbecker2, petersen, redhat, rkuska, scottt.tw, willschm, zboszor|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-11-19 16:25:57 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1133508|
Description Michael Wolf 2014-07-24 21:21:13 UTC
Description of problem: Would like the llvm package to be updated. Version-Release number of selected component (if applicable): current version is 3.4.10 How reproducible: N/A Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: In order to have llvm work on a PPC64-LE system we need that changes that are in the 3.5 version of llvm
Comment 1 Adam Jackson 2014-07-29 13:57:55 UTC
I'll try to get to this next week (before August 8).
Comment 2 Dan Horák 2014-08-14 14:47:52 UTC
<sharkcz> ajax: ping - llvm for ppc <ajax> sharkcz: trying. <ajax> sharkcz: f21's gcc won't build it on any arch, which is delightful. I guess, if IBM could help, it would be appreciated.
Comment 3 will schmidt 2014-08-19 14:50:59 UTC
> <ajax> sharkcz: f21's gcc won't build it on any arch, which is delightful. What is the error? If it is ... " undefined reference to ... getOption(unsigned int) const " give the patch referenced here a try: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140616/222509.html
Comment 4 Dan Horák 2014-08-21 15:22:57 UTC
<siddhesh> 04:57:29> ajax: is that on the latest rawhide? I fixed a bug in the __extern_always_inline definition a few days ago <siddhesh> 04:57:39> and I think that may have broken clang. <davids> siddhesh: ajax: I've been playing with the __extern_always_inline .... I'm seeing this on a F21 install <siddhesh> davids: glibc version? <davids> glibc-2.19.90-32.fc21.x86_64 <davids> siddhesh: it seems only __cplusplus is defined when sys/cdefs.h is included <davids> siddhesh: I'm also poking at the llvm build issues (for the sec-arch team) <siddhesh> davids: yeah, it was broken earlier (before 2012) until a 'fix' was put in <siddhesh> davids: the fix in turn broke all older gcc because the check was not correct for them. <davids> so ... is this a glibc or llvm issue? <siddhesh> davids: clang masquerades as 4.2 IIRC, thus not defining __extern_always_inline when it actually has support for it <siddhesh> davids: but then gcc was at fault for defining the feature macros (GNUC_STD_INLINE or something like that) when it didn't have the right semantics for it <siddhesh> and we're tied to gcc, because of which I had to choose between the two for now, to fix a couple of distro build failures. <davids> I see <davids> I do see this in cdefs.h: <davids> #if !defined __cplusplus || __GNUC_PREREQ (4,3) <davids> # if defined __GNUC_STDC_INLINE__ || defined __cplusplus <siddhesh> right, that is because the gnu_inline semantics are only reliable in gcc 4.3 onwards for c++ <davids> ajax, siddhesh: I can confirm that clang announces itself as gcc 4.2. I hacked sys/cdefs.h, changed __GNUC_PREREQ (4,3) go 4,2 ... and the llvm build could continue
Comment 5 David Sommerseth 2014-08-25 12:41:35 UTC
Discussed this with a glibc maintainer, and agreed we will try to get a fix into glibc-headers which resolves this issue. This can be tracked in bug #1133508. The proposed fix will enable the __extern_always_inline macro when using the clang compiler.
Comment 6 Zoltan Boszormenyi 2014-09-05 10:34:26 UTC
Created attachment 934733 [details] Fix LLVM_NOEXCEPT annotation for Error.cpp files Besides the linker and the GLIBC sys/cdefs.h (__extern_always_inline magic), I needed this patch to successfully compile LLVM 3.5.0 on Fedora 21 with glibc-2.19.90-35.fc21 and gcc-4.9.1-7.fc21. Compilation fails with "error: declaration of 'virtual ...' has a different exception specifier".
Comment 7 Zoltan Boszormenyi 2014-09-13 15:37:49 UTC
I tried to make an RPM out of llvm 3.5.0 but it fails at the install phase. I have these changes: - patch from the link https://bugzilla.redhat.com/show_bug.cgi?id=1123103#c3 - the patch I attached to this report - glibc change from https://bugzilla.redhat.com/show_bug.cgi?id=1133508#c3 , works against glibc-2.20-1.fc21 The install failure is: make: Entering directory '/home/zozo/rpmbuild/BUILD/llvm-3.5.0.src/tools/lldb/scripts/Python/modules/readline' llvm: Installing Release Shared Library /home/zozo/rpmbuild/BUILDROOT/llvm-3.5.0-0.1.fc21.x86_64/usr/lib64/llvm/readline.so llvm: Installing Release /home/zozo/rpmbuild/BUILD/llvm-3.5.0.src/Release/lib/python2.7/site-packages/readline.so to /home/zozo/rpmbuild/BUILDROOT/llvm-3.5.0-0.1.fc21.x86_64/usr/lib/python2.7/site-packages /usr/bin/rm: cannot remove '/home/zozo/rpmbuild/BUILDROOT/llvm-3.5.0-0.1.fc21.x86_64/usr/lib/readline.so': No such file or directory Makefile:94: recipe for target 'install-local' failed make: *** [install-local] Error 1 It looks like that install-local:: in the generated Makefile contains this extra line at the very end: $(Verb) $(RM) "$(DESTDIR)$(prefix)/lib/$(LIBRARYNAME)$(SHLIBEXT)" Many other generated Makefiles use "$(RM) -f" so they don't fail. Simply passing RM="/usr/bin/rm -f" to ./configure fixes it. Then there are a bunch of installed but unpackaged files under .../python2.7/site-packages.
Comment 8 David Sommerseth 2014-09-17 17:18:13 UTC
I tried another build on ppc64, with a similar fix as is attached to this bz + the final glibc patch for the sys/cdefs.h header. But I get more issues: llvm: Linking Release Shared Library libLLVM-3.5.so /home/dsommers/devel/fedora/llvm/llvm-3.5.0.src/Release/lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.o):(.data.rel.ro._ZTIN4llvm6object13ELFObjectFileINS0_7ELFTypeILNS_7support10endiannessE1ELm2ELb0EEEEE[_ZTIN4llvm6object13ELFObjectFileINS0_7ELFTypeILNS_7support10endiannessE1ELm2ELb0EEEEE]+0x10): undefined reference to `typeinfo for llvm::object::ObjectFile' So it's still a bit more to dig into.
Comment 9 Maxim Prohorenko 2014-10-11 17:28:39 UTC
Linux qosmio 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux llvm: Linking Release Shared Library libLLVM-3.5.so /home/maxim/rpmbuild-all/llvm/rpmbuild/BUILD/llvm-3.5.0.src/Release/lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.o):(.data.rel.ro._ZTIN4llvm6object13ELFObjectFileINS0_7ELFTypeILNS_7support10endiannessE1ELm2ELb0EEEEE[_ZTIN4llvm6object13ELFObjectFileINS0_7ELFTypeILNS_7support10endiannessE1ELm2ELb0EEEEE]+0x10): undefined reference to `typeinfo for llvm::object::ObjectFile'
Comment 10 Maxim Prohorenko 2014-10-11 18:43:36 UTC
Download bin from llvm export CC=~/proj/clang+llvm-3.5.0-x86_64-fedora20/bin/clang CXX=~/proj/clang+llvm-3.5.0-x86_64-fedora20/bin/clang++ and build OK
Comment 11 Robert Kuska 2014-10-22 06:44:15 UTC
There is a successful scl build of llvm-3.5 in copr. https://copr.fedoraproject.org/coprs/dwrobel/scl-llvm-35/
Comment 12 Nick Thomas 2014-10-29 13:50:41 UTC
OpenGL 3.3 support for AMD GPUs is claimed to depend on LLVM 3.5 in some cases: http://www.x.org/wiki/RadeonFeature/#18
Comment 13 Jens Petersen 2014-11-05 04:21:56 UTC
llvm-3.5 seems to break Haskell ghc programs completely (ie on ARM). :-( Even ghc-7.8 which is not yet built in Rawhide does not support llvm-3.5. So I would really appreciate holding off on llvm-3.5 for f21 for the time being.
Comment 14 Andy Grover 2014-11-05 20:35:54 UTC
(In reply to Jens Petersen from comment #13) > llvm-3.5 seems to break Haskell ghc programs completely (ie on ARM). :-( > Even ghc-7.8 which is not yet built in Rawhide does not support llvm-3.5. > > So I would really appreciate holding off on llvm-3.5 for f21 for the time > being. Hi Jens, is there a separate bz for that issue?
Comment 15 Jens Petersen 2014-11-06 09:27:19 UTC
(In reply to Andy Grover from comment #14) > Hi Jens, is there a separate bz for that issue? I can surely file one but not sure if it will help much other than document the current rawhide issue. :) I posted a review request for llvm34 today (bug 1161014) which ghc will be able to use for compilation on ARM. If we backport llvm-3.5 and llvm34 to F21 then I don't think there should be a big problem as far as ghc is concerned. It is very late now in the F21 development cycle for a major version bump though...
Comment 16 Jens Petersen 2014-11-06 09:47:43 UTC
Okay additionally I filed bug 1161049 about the ghc "schedule: re-entered unsafely" runtime errors on armv7.
Comment 17 Jens Petersen 2014-11-19 10:37:05 UTC
llvm34 is now in f22 rawhide and working with ghc on arm.
Comment 18 Adam Jackson 2014-11-19 16:25:57 UTC
3.5 is already present in F22; I'll backport it to F21 after release as well. To follow progress on that please watch bug #1158661.
Comment 19 Jens Petersen 2014-11-20 08:44:08 UTC
*** This bug has been marked as a duplicate of bug 1158661 ***
Comment 20 Neal Becker 2014-12-18 12:55:32 UTC
Can we perhaps have a build of 3.5 for F21 in copr?