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
Steps to Reproduce:
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:
<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> 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: 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.
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.
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'
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.
OpenGL 3.3 support for AMD GPUs is claimed to depend on LLVM 3.5 in some cases:
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
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?