Bug 1123103 - Update the llvm version to 3.5
Summary: Update the llvm version to 3.5
Keywords:
Status: CLOSED DUPLICATE of bug 1158661
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: 21
Hardware: ppc64le
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1133508
Blocks: F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2014-07-24 21:21 UTC by Michael Wolf
Modified: 2014-12-18 12:55 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-19 16:25:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Fix LLVM_NOEXCEPT annotation for Error.cpp files (1.71 KB, patch)
2014-09-05 10:34 UTC, Zoltan Boszormenyi
no flags Details | Diff

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[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.

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[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.

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[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'

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?


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