llvm-svn
This is an Arch Linux PKGBUILD for the LLVM compiler infrastructure, the Clang frontend, and the various tools associated with it. It's available in the Arch User Repository as llvm-svn.
Main development is in the master branch, while the AUR git repo is mirrored by the aur branch.
IMPORTANT INFORMATION
PLEASE READ THIS ONE CAREFULLY
This is a fairly complex package. The only recommended and supported method of building is in a clean chroot as described on the Arch Wiki. A crude example is also provided further below. The use of AUR helpers (yaourt, pacaur, etc.) in particular is discouraged; it may or may not work for you.
Also, unlike the official packages, which provide the latest stable releases, this one builds the code straight from the SVN source repository, where development is constantly taking place. Thus, it brings all the latest bells and whistles, but also tends to bring and all the latest bugs. It is therefore strongly recommended to use this LLVM/Clang build only for testing. Use in production should only be reserved for cases where you do need a particular feature (or a fix for some bug), which are not yet available in the stable releases.
On failing regression tests
Note that failing regression tests do not necessarily indicate a problem with the package. Such failures are fairly normal for an actively developed code (i.e. SVN trunk or Git master). If this happens, wait for some time before trying the build again: a few hours to a day or two at most should be enough. If you desperately need the package built right away, you may also comment out the make check and make check-clang lines or append || true to them, but do this only if you really know what you're doing and why.
Binary packages
Pre-built, binary packages are available from two unofficial repositories:
-
lordheavy's mesa-git, which may be particularly useful for those who need LLVM solely as a Mesa dependency. Note that the packages are built against the [testing] repos. lordheavy is an Arch Linux developer and trusted user (TU).
-
kerberizer's llvm-svn, which is automatically rebuilt every 6 hours from this PKGBUILD and the latest SVN code. The packages are built against the [core/extra] repos. kerberizer is the current maintainer.
Both repos provide x86_64 and multilib packages. kerberizer's repo is also PGP signed.
Signature "unknown trust" error
For PGP signed unofficial repositories to work correctly their signing key needs to be added to Pacman's keyring. The process is described here. For the llvm-svn repo in particular, it boils down to:
- Fetch the necessary key from a keyserver:
# pacman-key -r 0x76563F75679E4525
- Verify the key fingerprint; it must be exactly
D16C F22D 27D1 091A 841C 4BE9 7656 3F75 679E 4525:
$ pacman-key -f 0x76563F75679E4525
- If the fingerprint matches, sign the key locally:
# pacman-key --lsign-key 0x76563F75679E4525
If using LLVM as Mesa dependency
You may find helpful the topic "mesa-git - latest videodrivers & issues" on the Arch Linux forums.
Building in a clean chroot example
If you need a more detailed and specific example on how to build this package in a clean chroot, a crude excerpt from the build script of the kerberizer's binary repo is presented here. You can also check the full script.
It is meant to allow building lib32-llvm-svn too, hence why gcc-multilib is used. The code 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. Note that the latest versions of systemd mount /tmp with the nosuid flag. You need to turn this flag off before building on /tmp, or else the build will fail.
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 <[email protected]>\"/' \
-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).
Bugs
- When an older or generally different version of llvm-ocaml{,-svn} is installed on the build system, the build would likely fail with inconsistent assumptions over interface errors. The PKGBUILD will detect such situation and spit out an appropriate suggestion: namely, to either uninstall any currently installed llvm-ocaml* package before building, or, preferably, to build in a clean chroot, as described on the Arch Linux wiki.