Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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


Attachments (Terms of Use)
Fix LLVM_NOEXCEPT annotation for Error.cpp files (deleted)
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.