Package Details: clang-svn 3.9.0svn_r274222-1

Git Clone URL: https://aur.archlinux.org/llvm-svn.git (read-only)
Package Base: llvm-svn
Description: C language family frontend for LLVM
Upstream URL: http://clang.llvm.org/
Keywords: clang llvm
Licenses: custom:University of Illinois
Groups: llvm-toolchain-svn
Conflicts: clang
Provides: clang
Replaces: clang
Submitter: None
Maintainer: kerberizer
Last Packager: kerberizer
Votes: 69
Popularity: 0.667333
First Submitted: 2007-08-02 07:15
Last Updated: 2016-06-30 12:08

Dependencies (12)

Required by (184)

Sources (5)

Latest Comments

kerberizer commented on 2016-06-30 12:56

[NOTICE] As expected, D18035 has finally been committed today and so I've removed the patch from our package. I'm also copying here the patch author's request for additional testing:

"I decided to commit this patch without waiting for GCC response to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71712 (that is last compatibility issues in comparison with GCC6) so more people could test Clang implementation of ABI tags on real apps and report issues if any. All, please let me know (file bug and add me in CC) if you observe any issues with abi_tag implementation in Clang."

http://reviews.llvm.org/D18035

kerberizer commented on 2016-06-29 17:25

[NOTICE] The old version of D18035 was no longer applying cleanly, so I updated it to the very latest (and probably final before merging) version from today: http://reviews.llvm.org/D18035

edit: missed a preposition

kerberizer commented on 2016-06-21 18:45

[NOTICE] There is a new version of the D18035 patch. However, in the author's own words, "this patch set was not tested extensively on real world apps so it might have be worse than previous one". For this reason, for the time being I'm _not_ going to update our package with it. At the same time, just like the author of the patch I do urge those of you who use Clang more actively to test the patch on your own and report back any issues in the thread here: http://reviews.llvm.org/D18035

gentoofu commented on 2016-06-15 01:17

The problem I was having may have been fixed with the new version of make that just came out of stable repo.

kerberizer commented on 2016-06-11 17:45

It also seems that one of the regression tests, 'LLVM :: tools/gold/X86/thinlto_alias.ll', is failing when building on i686. I don't know how many of you actually build this on 32-bit systems, and so how many of you are affected. Considering that nobody has complained yet, probably not too many. I'll take a look at it at some point, but recently I've been quite busy with my day job, so it might take some time. In other words, if some of you _are_ affected, please bug me harder (unless you can even find the cause yourself).

kerberizer commented on 2016-06-10 22:14

[NOTICE] I've finally fixed the problem with lib32-llvm-svn. This is the only reason for the version bump; llvm-svn is not changed in any way. The good news is also that the binary repo will begin updating regularly (i.e. every 6 hours) again. Sorry this took me so awfully long.

kerberizer commented on 2016-06-01 13:24

@gentoofu, thanks for the feedback. I'm also really glad that the examples have been useful to you. Probably I'll consider compiling some kind of FAQ on using this PKGBUILD to put into a sticky comment.

Meanwhile, a notice to everyone who compiles lib32-llvm-svn: there seems to be some bug with libffi. For some reason, an attempt is made to link the 32-bit LLVM shared library to the 64-bit libffi.so. I suspect this has something to do with the recent Cmake-related commits to LLVM, but I'll have to investigate further.

gentoofu commented on 2016-06-01 05:48

kerberizer, I find your instructions to be more useful than the wiki's; thanks. llvm-svn 3.9.0svn_r271360-1 builds fine on clean chroot.

kerberizer commented on 2016-05-30 14:25

@LinguinePenguiny, do you build in a clean chroot? I did some additional testing on my own desktop system (which, BTW, happens to also be an FX-8350), but I couldn't reproduce the problem, I'm afraid. For me, the testing succeeds even when using makepkg outside of a clean chroot. However, each system setup can be specific enough to cause unique problems, which is why I always recommend building in a clean chroot.

Just in case someone finds this information helpful, here are some example commands how to build in a clean chroot. I still advise consulting the Arch Wiki though.[1] The example (it's actually a crude excerpt from the build script that I use for the binary repo) is meant to allow building lib32-llvm-svn too, hence why gcc-multilib is used. It takes advantage of multiple cores when building and compressing (the example here is tailored to an 8-core/threads system). The user's ccache cache is utilised as well, so frequent rebuilds can be much faster. If you don't sign your packages, omit the lines mentioning PACKAGER and GPGKEY, otherwise they need to be set correctly. The chroot ("${x86_64_chroot}") is best set up in /tmp, but this requires a lot of RAM (most likely at least 32 GB, since /tmp is by default half the size of the physical RAM detected); second best solution is on an SSD. The latter goes for ~/.ccache as well.

$ cd /path/to/where/llvm-svn/is/cloned

$ x86_64_chroot="/chroot/x86_64"

$ sudo mkdir -p "${x86_64_chroot}/root"

$ sudo /usr/bin/mkarchroot \
-C /usr/share/devtools/pacman-multilib.conf \
-M /usr/share/devtools/makepkg-x86_64.conf \
-c /var/cache/pacman/pkg \
"${x86_64_chroot}/root" \
base-devel ccache

$ sudo /usr/bin/arch-nspawn "${x86_64_chroot}/root" /bin/bash -c "yes | pacman -Sy gcc-multilib"

$ sudo /usr/bin/arch-nspawn "${x86_64_chroot}/root" /bin/bash -c \
"echo -e \"CCACHE_DIR='/.ccache'\nXZ_DEFAULTS='--threads=8'\" >>/etc/environment ; \
sed \
-e 's/^#MAKEFLAGS=.*$/MAKEFLAGS=\"-j9\"/' \
-e '/^BUILDENV=/s/\!ccache/ccache/' \
-e 's/^#PACKAGER=.*$/PACKAGER=\"Some One <someone@somewhere.com>\"/' \
-e 's/^#GPGKEY=.*$/GPGKEY=\"0x0000000000000000\"/' \
-i /etc/makepkg.conf"

$ sudo /usr/bin/makechrootpkg -c -d ~/.ccache:/.ccache -r "${x86_64_chroot}"

It's advisable to always start this from scratch, i.e. don't reuse the old chroot, but create it anew for each build (it uses the local pacman cache, so doesn't waste bandwidth, and if located in /tmp or on an SSD, is pretty fast).

----
1. https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

LinguinePenguiny commented on 2016-05-30 09:54

I do also get that build failure, and have for a few weeks. I run an FX-8350 CPU.

http://pastebin.com/yu9VeefG (1 month expiry time from May 30th, 2016)

All comments