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?