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
I'll try to get to this next week (before August 8).
<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.
> <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
<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
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.
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".
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[6]: Entering directory '/home/zozo/rpmbuild/BUILD/llvm-3.5.0.src/tools/lldb/scripts/Python/modules/readline' llvm[6]: Installing Release Shared Library /home/zozo/rpmbuild/BUILDROOT/llvm-3.5.0-0.1.fc21.x86_64/usr/lib64/llvm/readline.so llvm[6]: 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[6]: *** [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.
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[1]: 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.
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[1]: 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'
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
There is a successful scl build of llvm-3.5 in copr. https://copr.fedoraproject.org/coprs/dwrobel/scl-llvm-35/
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
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.
(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?
(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...
Okay additionally I filed bug 1161049 about the ghc "schedule: re-entered unsafely" runtime errors on armv7.
llvm34 is now in f22 rawhide and working with ghc on arm.
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.
*** This bug has been marked as a duplicate of bug 1158661 ***
Can we perhaps have a build of 3.5 for F21 in copr?