Package Details: clang-svn 4.0.0svn_r280666-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: 72
Popularity: 2.641204
First Submitted: 2007-08-02 07:15
Last Updated: 2016-09-05 18:27

Dependencies (12)

Required by (210)

Sources (5)

Pinned Comments

kerberizer commented on 2016-08-11 00:39

[NOTICE] This is the updated pinned comment, a.k.a. README. If you already know the package well, you may safely ignore it.

IMPORTANT INFORMATION // PLEASE READ 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.[1] A crude example is also provided further below. The use of AUR helpers (yaourt, pacaur, etc.)[2] in particular is discouraged; it may or may not work for you.

* * *

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.

* * *

Pre-built, binary packages are available from two unofficial repositories:

o lordheavy's [mesa-git],[3] 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).

o kerberizer's [llvm-svn],[4] 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 (yours truly) is the current maintainer.

Both repos provide x86_64, i686 and multilib packages. kerberizer's repo is also PGP signed.

* * *

Those who use LLVM as a Mesa dependency may also find helpful the topic "mesa-git - latest videodrivers & issues" on the Arch Linux forums.[5]

* * *

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 follows. 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 [sic] 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 <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
2. https://wiki.archlinux.org/index.php/AUR_helpers
3. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#mesa-git
4. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn
5. https://bbs.archlinux.org/viewtopic.php?id=212819

Latest Comments

kerberizer commented on 2016-09-05 18:32

[NOTICE] TL;DR: The regression tests should pass fine now.

The problem which @electricprism was facing (and likely everyone else) persists for several days already. Unfortunately, I don't have the time to search for the root cause, but it's a simple matter of ld.so not finding the built shared lib when loading the test, so I've committed a simple fix which sets LD_LIBRARY_PATH appropriately while running "make check".

kerberizer commented on 2016-09-04 04:10

@electricprism, please see the pinned comment.

electricprism commented on 2016-09-04 04:06

http://pastebin.com/pfmd4f0P

6 errors, exiting.
make[3]: *** [test/CMakeFiles/check-llvm.dir/build.make:58: test/CMakeFiles/check-llvm] Error 2
make[2]: *** [CMakeFiles/Makefile2:88672: test/CMakeFiles/check-llvm.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:68845: test/CMakeFiles/check.dir/rule] Error 2
make: *** [Makefile:16694: check] Error 2
==> ERROR: A failure occurred in check().
Aborting...
==> ERROR: Makepkg was unable to build llvm-svn.

kerberizer commented on 2016-08-14 20:08

[NOTICE] For those who use the binary repo and might be wondering why my key has expired: it actually had been duly extended on the day before it would expire and the new signature had been uploaded to the PGP keyservers. So, if the key shows to you as expired, you just need to refresh it in your pacman keyring, e.g. "sudo pacman-key --refresh-keys 0x76563F75679E4525".

kerberizer commented on 2016-08-11 00:39

[NOTICE] This is the updated pinned comment, a.k.a. README. If you already know the package well, you may safely ignore it.

IMPORTANT INFORMATION // PLEASE READ 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.[1] A crude example is also provided further below. The use of AUR helpers (yaourt, pacaur, etc.)[2] in particular is discouraged; it may or may not work for you.

* * *

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.

* * *

Pre-built, binary packages are available from two unofficial repositories:

o lordheavy's [mesa-git],[3] 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).

o kerberizer's [llvm-svn],[4] 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 (yours truly) is the current maintainer.

Both repos provide x86_64, i686 and multilib packages. kerberizer's repo is also PGP signed.

* * *

Those who use LLVM as a Mesa dependency may also find helpful the topic "mesa-git - latest videodrivers & issues" on the Arch Linux forums.[5]

* * *

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 follows. 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 [sic] 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 <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
2. https://wiki.archlinux.org/index.php/AUR_helpers
3. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#mesa-git
4. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn
5. https://bbs.archlinux.org/viewtopic.php?id=212819

kerberizer commented on 2016-07-25 18:28

@okabekudo, really glad to hear it, thank you! BTW, if you don't mind using other people's binary repos, you may save further time with @lordheavy's (who's an Arch Linux dev and TU) or mine...

https://bbs.archlinux.org/viewtopic.php?id=212819

okabekudo commented on 2016-07-25 16:51

@kerberizer I actually did yep with the -c flag but I tried again. With deleting my chroot folder and all and then it successfully built! Man I'm happy. No more waiting hours for llvm-svn to update :D

kerberizer commented on 2016-07-25 00:52

@okabekudo, I'm not seeing any problems on my build box. Are you building in a clean chroot?

kerberizer commented on 2016-07-24 19:51

@okabekudo, strange, indeed. The last automated build that I run every 6 hours has passed successfully. I'll start it manually and see if there might be some change upstream that is causing the problem.

okabekudo commented on 2016-07-24 19:19

make[3]: *** No rule to make target '/build/llvm-svn/src/llvm/include/mlvm/Target/TargetOpcodes.h', needed by 'lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600EmitClauseMarkers.cpp.o'. Stop.
make[2]: *** [CMakeFiles/Makefile2:5004: lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
[ 79%] Built target LLVMMipsAsmParser
[ 79%] Built target LLVMMipsDesc
[ 79%] Built target LLVMMSP430CodeGen
[ 82%] Built target LLVMMipsCodeGen
[ 85%] Built target LLVMHexagonCodeGen
make[1]: *** [CMakeFiles/Makefile2:111320: docs/CMakeFiles/ocaml_doc.dir/rule] Error 2
make: *** [Makefile:22648: ocaml_doc] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Build failed, check /home/michel/chroot/michel/build

Getting this right now. Probably not due to the makeflags though.

kerberizer commented on 2016-07-24 17:47

@okabekudo, I think I understand what you might be refererring to: there used to be some complications with the OCaml bindings, which weren't necessarily caused by the multithreaded building, but may had been exacerbated by it. This has however been finally fixed in December, if I remember correctly. So, yes, please do test and let me know if you still find problems.

okabekudo commented on 2016-07-24 17:16

@keberizer Well in the past that means atmost 8 months ago it would break with makeflags -j. So I haven't tried since then. So that was just a generic question so far. But if you say it worked since you took over the maintainership I will test it now and report back.

kerberizer commented on 2016-07-24 17:05

@okabekudo, this package __does__ build with parallel make threads as many as 64, and as far as I can remember it has been that way ever since I took over the maintainership a year ago. I do see there used to be such problems in the past, but the last relevant comments seem to be from 2013. So, do you have a problem with the PKGBUILD __now__, or was it just a generic question? Thank you.

okabekudo commented on 2016-07-24 16:34

Does this still break when using makeflags -j? If it does please add options=('!makeflags') to the PKGBUILD. It's a pain editing either my makepkg.conf or the PKGBUILD everytime I update llvm-svn. And you probably know this it takes hours building llvm-svn. So it's crucial to get the paralell jobs fixed.

kerberizer commented on 2016-07-21 15:40

[NOTICE] Probably you've noticed that LLVM is now at version 4.0.0svn. If you're using it for Mesa, DON'T forget to also rebuild the latter after you update LLVM. The reason is that the name of the shared lib has also changed and the dynamic linker would have trouble finding the old file. Alternatively, you may temporarily create a symlink from /usr/lib/libLLVM-3.9svn.so to /usr/lib/libLLVM-4.0svn.so, which can be especially helpful if you can't get to the desktop because of the problem. Once Mesa--and any other applications that had been linked to the LLVM shared lib--are recompiled however, it's better to remove that symlink.

kerberizer commented on 2016-07-21 15:35

@Enverex, tests do fail from time to time. Currently, we don't apply any local modifications to the code that might have otherwise been the cause, so these problems usually get resolved upstream within a day or two. If for some reason you do need to use the current code ASAP, temporarily comment out or add "|| true" to the make check lines.

Enverex commented on 2016-07-21 15:28

Doesn't compile for me as it fails one of the tests:

FAIL: Clang :: CodeGen/2008-03-24-BitField-And-Alloca.c (1332 of 9662)

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)

kerberizer commented on 2016-05-29 19:48

@gentoofu, could you possibly try building in a clean chroot?

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

gentoofu commented on 2016-05-29 19:09

Yes. I also tried changing the PKGBUILD to pkgver=3.9.0svn_r271186 and use makepkg, and I get the same error.

Lone_Wolf commented on 2016-05-28 13:56

llvm-svn 3.9.0svn_r271112-1 builds fine here.

The log shows you were building with yaourt, does the build fail for you when you build with makekpkg ?

gentoofu commented on 2016-05-28 05:24

Am I the only one who's getting this error?
http://pastebin.com/PSKbGhd5

kerberizer commented on 2016-05-23 15:14

[NOTICE] The D18035 patch has been updated to the latest revision and the regression tests pass successfully again.

kerberizer commented on 2016-05-21 19:38

@rectangleboy, thank you for the report. It's a bit confusing that I've been seeing different errors these days: yours is yet another one. Right now, however, the clean code passes all tests without problems, and only with D18035 applied is one test still failing. I haven't had the time to follow the recent commits in detail, so I can only guess that perhaps some of those commits might have caused the regression tests to fail, and eventually got fixed -- but unsurprisingly, the patch didn't get the appropriate fix (since it hasn't yet been committed itself).

Long story short, I've informed the patch author about the problem and am looking forward to his reply: http://reviews.llvm.org/D18035

rectangleboy commented on 2016-05-21 07:59

Can confirm. Regression test is killing this build for me.

Hopefully this image helps: http://i.imgur.com/NIptD4L.png

kerberizer commented on 2016-05-18 23:18

[NOTICE] Apparently, one of the Clang regression tests has been failing for the last about 24 hours. I'll take a look tomorrow if it isn't connected to the D18035 patch.

kerberizer commented on 2016-05-11 20:53

@wolf, I'm afraid it's not quite possible to use llvm-svn with Mesa from the official Arch package when using the AMD open source drivers. I don't recommend using symlinks either, because the LLVM shared library changes a lot (you'll likely get undefined symbol errors, but that's probably the lesser evil). The only proper solution is building an up-to-date Mesa, preferably from the mesa-git package here in AUR. Or using a prebuilt one from the repos that @lordheavy and I think @Lone_Wolf maintain.

wolf commented on 2016-05-11 19:41

This package breaks opengl on my ATI GPU system. The dri looks for libllvm-3.7.so or something. Didn't try if symlink is enough to get it work, will do.

kerberizer commented on 2016-05-09 20:28

[NOTICE] Two small changes, the second of which is still worth paying attention to:
* The D18035 patch has been updated to the latest revision: http://reviews.llvm.org/D18035
* The post-build regression tests for LLVM and Clang have been enabled. This may cause the builds to fail sometimes unexpectedly, but there's usually a good reason for that and you'll likely not want to use such builds anyway.

kerberizer commented on 2016-04-20 20:23

@wolf, it's a split package. The same PKGBUILD is used to build all the seven packages listed in the section "Packages" when you look at the package base...

https://aur.archlinux.org/pkgbase/llvm-svn/

More information on how the split packages work is available from the Arch wiki...

https://wiki.archlinux.org/index.php/PKGBUILD

wolf commented on 2016-04-20 20:15

Out of curiosity, why is Git Clone URL ending with llvm-svn? Is this package clang or just llvm?

kerberizer commented on 2016-03-16 17:36

[NOTICE] The D18035 patch has been updated to the latest revision: http://reviews.llvm.org/D18035

comgunner commented on 2016-03-16 15:39

kerberizer | Lone_Wolf


Thank you very much, is already working, having nice day and congratulations on your work

kerberizer commented on 2016-03-16 15:26

@comgunner, you need to add the PGP key to the Pacman's keyring as described here:

* https://wiki.archlinux.org/index.php/Unofficial_user_repositories
* https://wiki.archlinux.org/index.php/Pacman/Package_signing#Adding_unofficial_keys

1) Fetch the key from a keyserver...
$ sudo pacman-key -r 0x76563F75679E4525

2) Verify the key fingerprint: it must be __exactly__ "D16C F22D 27D1 091A 841C 4BE9 7656 3F75 679E 4525"...
$ pacman-key -f 0x76563F75679E4525

3) If the fingerprint matches, sign the key locally...
$ sudo pacman-key --lsign-key 0x76563F75679E4525

@Lone_Wolf, thanks for answering this one, mate!

comgunner commented on 2016-03-16 14:55

Good day , from the repository me indicates the following

error: llvm-svn: signature from "Luchesar V. ILIEV (Arch Linux package signing key) <luchesar.iliev@gmail.com>" is unknown trust

error: la base de datos «llvm-svn» no es válida (base de datos no válida o dañada (firma PGP))

Lone_Wolf commented on 2016-03-16 09:53

la opción no es válida '--pkg'

That option was removed in pacman 5.x .
It seems your aur helper needs to be updated.

Switch to makepkg without a helper,or use kerberizer unofficial repo.

comgunner commented on 2016-03-16 00:03

I can not install, could help

==> ¿Instalar únicamente llvm-svn ? [S/n]
==> -------------------------------------
==>
makepkg: la opción no es válida '--pkg'
==> ERROR: Makepkg no ha podido compilar llvm-svn.
==> ¿Reiniciar la compilación de llvm-svn? [s/N]
==> --------------------------------------------

kerberizer commented on 2016-03-10 13:37

[NOTICE] The Sema part of D12834 has already been incorporated upstream with r263015. For this reason, it's been replaced in the PKGBUILD with the respective mangler part from D18035 that's yet to be committed upstream.

References:
https://llvm.org/bugs/show_bug.cgi?id=23529
http://reviews.llvm.org/D12834
http://reviews.llvm.org/D17567
http://reviews.llvm.org/D18035

kerberizer commented on 2016-03-09 01:22

[NOTICE] The D12834 patch has been rebased again and should apply cleanly now.

kerberizer commented on 2016-02-27 15:01

[NOTICE] Regarding the lto.h problem: it was caused by r262066 and should be fixed now.
Ref: https://github.com/llvm-mirror/llvm/commit/995ce72c1218ac534e4cd3619aec2da148b615a9

kerberizer commented on 2016-02-27 05:38

[NOTICE] There seems to be some problem with lto.h being present in several of the packages simultaneously. I'll look into it later today.

FadeMind commented on 2016-02-24 17:19

@kerberizer. Thanks for quick reply. In future I will post suggestions in main thread.

Regards

kerberizer commented on 2016-02-24 16:32

@FadeMind, the out-of-date flag is for flagging the package out of date, not for suggestions. Anyway, I've already explained why I'm very reluctant to switch the svn URLs to https: the SSL/TLS configuration on llvm.org is __bad__. The Qualys SSL test suite rates the site with the worst possible grade, F. This hasn't changed, and the problems are not only critical, but numerous as well.

https://www.ssllabs.com/ssltest/analyze.html?d=llvm.org

It's probably a good idea to open a ticket on LLVM's issue tracker for this problem, but I don't know if they'd be willing or have the time to fix it.

kerberizer commented on 2016-02-16 18:16

[HEADS UP] Users of "{lib32-,}llvm-svn", "{lib32-,}mesa-git" and AMD video cards MUST recompile Mesa

If __all__ of the following are true for you...
* you use an AMD video card with the open source drivers,
* you use "{lib32-,}mesa-git" from AUR, with version < g0bba5ca,
* you use "{lib32-,}llvm-svn" from AUR, with version >= r260919,
...then you __must__ recompile the Mesa packages (or possibly upgrade again from the "mesa-git" binary repo you use).

The reason is explained in this Mesa commit:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=0bba5ca468cdcd1f6f9bb6736c8a75e43fbe0cd5

If Mesa is not recompiled, you'll face errors of the type:

libGL: dlopen /usr/lib/xorg/modules/dri/radeonsi_dri.so failed (/usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: LLVMAddTargetData)

Please note that with the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

chrbayer commented on 2016-02-16 13:32

@kerberizer, looks like no one has missed this so far...

I agree it would be best to fill in a bug report upstream. If you would do it, it would be fine for me! Maybe you are more experienced in filling this bug report, but of course I do not want you to lose time...

Thank you very much!

kerberizer commented on 2016-02-16 13:22

@chrbayer, from what I can tell, the BlocksRuntime is missing the required CMake configuration: there isn't a CMakeLists.txt in its own directory...

https://github.com/llvm-mirror/compiler-rt/tree/master/lib/BlocksRuntime

...and there's no provision for it in the parent CMakeLists.txt too...

https://github.com/llvm-mirror/compiler-rt/blob/master/lib/CMakeLists.txt

It _is_ referred to in the test suite CMakeLists.txt, so obviously hasn't been entirely forgotten during the transition from autotools...

https://github.com/llvm-mirror/compiler-rt/blob/master/test/CMakeLists.txt

...but even there it is commented out, albeit (apparently) for different reasons.

I suppose I could try fixing this on my own, but the best way -- if I'm not mistaken in my observations, of course -- would probably be to file a bug report in the LLVM issue tracker. Should I do it or would you do it instead?

chrbayer commented on 2016-02-16 08:56

I am looking for the BlocksRuntime but it does not seem to be included in the compiler-rt-svn package. Does it have to be enabled during build?

Thank you very much in advance!

kerberizer commented on 2016-02-15 22:28

[NOTICE] The D12834 patch is rebased and Clang should build fine now.

kerberizer commented on 2016-02-15 19:16

[NOTICE] There is again a problem with the GCC abi_tag support patch. I'll be looking into it, but I'm rather busy, so unfortunately I cannot promise anything on how long it'll take.

kerberizer commented on 2016-02-03 09:42

[NOTICE] The D12834 patch is rebased and should apply cleanly now.

kerberizer commented on 2016-02-03 08:54

[NOTICE] There is again a problem with the GCC abi_tag support patch. I'll be looking into it.

kerberizer commented on 2016-01-30 01:01

[NOTICE] pkgver() is fixed and should again produce the correct version.

kerberizer commented on 2016-01-29 23:51

[NOTICE] There is a problem with pkgver() because of the final retirement of the autotools build and files. While we have been using Cmake in our PKGBUILD for a long time already, pkgver() still relies on the now non-existent autotools files. I'm working on a fix that should be ready really soon.

kerberizer commented on 2016-01-20 11:22

The package is updated: the new patch should now apply cleanly; the Clang segfault does seem fixed too. The binary repo will be updated shortly as well.

kerberizer commented on 2016-01-20 09:57

@mnovick1988, thanks for pointing that out. Speaking of this, there's been a newer patch on http://reviews.llvm.org/D12834 for a few days now, which I've been planning to push here, but just couldn't find the time for it. It still needed a couple of updates to apply cleanly to latest code, and as soon as I'm finished testing it, I'll update the package. Perhaps more importantly, according to @foutrelis (who maintains the official LLVM/Clang Arch packages), this new version of the patch solves the segmentation faults with Clang in some specific cases, which were mentioned several comments below.

mnovick1988 commented on 2016-01-20 03:04

patches are failing

kerberizer commented on 2016-01-14 10:34

[HEADS UP] Users of `{lib32-,}llvm-svn`, `{lib32-,}mesa-git` and AMD video cards MUST recompile Mesa

If ALL of the following are true for you:
* you use an AMD video card with the open source drivers,
* you use `{lib32-,}mesa-git` from AUR,
* you use `{lib32-,}llvm-svn` from AUR,
* you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo,
then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use).

The reason is the recent branching of LLVM/Clang 3.8 and bumping the development version to 3.9, which also affects the shared library version. If Mesa is not recompiled, with the new {lib32-,}llvm-svn packages you'll face errors of the type:

gbm: Last dlopen error: libLLVM-3.8svn.so: cannot open shared object file: No such file or directory
(EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (libLLVM-3.8svn.so: cannot open shared object file: No such file or directory)

Please note that for the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

kerberizer commented on 2016-01-14 03:41

[NOTICE] Future release 3.8 has been branched a few hours ago, so welcome to LLVM/Clang 3.9! ;)

kerberizer commented on 2015-12-20 02:07

@zanny, I've just compiled successfully a debug version on my local machine. Is there anything else that you change in the PKGBUILD besides switching CMAKE_BUILD_TYPE from Release to Debug? Also, I noticed the last night that the build would fail several times in a row, most likely due to some problematic commit (it went away before I found time to investigate), so could your problem be just an unfortunate coincidence?

zanny commented on 2015-12-19 20:13

Trying to build a debug mode to test some Mesa bugs and I'm getting:

-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed
CMake Error at tools/clang/tools/CMakeLists.txt:1 (create_subdirectory_options):
Unknown CMake command "create_subdirectory_options".

This function is defined in AddLLVM.cmake, but the build is not recognizing it. The other AUR repo llvm-debug gets past this stage fine but fails for its own reasons in the compile step.

kerberizer commented on 2015-12-16 21:51

Just FYI, the abi_tag patch seems to provoke a segmentation fault in Clang in certain cases. See the last comment here: http://reviews.llvm.org/D12834

kerberizer commented on 2015-12-13 12:33

[HEADS UP] Important updates

I'll be pushing shortly three important updates:

1. A set of patches for Clang, which add support for the new GCC's abi_tag attribute. This should fix linking to libraries that provide interfaces based on the new dual ABI model. For a practical example of the issue, see this Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917

2. `make all` will now be executed before `make ocaml_doc` as discussed here earlier. Please let me know if you encounter problems with this.

3. Any installed on the system LLVM OCaml bindings are now considered incompatible. Previously, if the OCaml bindings on the system were of the same version as the current build (which would happen pretty rarely though, except when doing instant rebuilds) the PKGBUILD wouldn't complain. I've had however a case when even the same version bindings caused a problem, and so decided it's better to play safe. In any case, and as always, building in a clean chroot is highly recommended, which would avoid such issues altogether.

kerberizer commented on 2015-12-11 15:21

[NOTICE] The binary repo is back online.

I'm also aware of the dual ABI issue with Clang and will be looking into it. For further reference:
* https://llvm.org/bugs/show_bug.cgi?id=23529
* http://reviews.llvm.org/D12834

kerberizer commented on 2015-12-10 20:22

I'm afraid the binary repo will be down for longer than I expected. I'll let you know once it's back on-line. Again, I'm really sorry for this inconvenience.

kerberizer commented on 2015-12-09 22:12

[NOTICE] Due to upstream link problems, the binary repo is currently unavailable. Unfortunately, at the moment no estimate on the time needed to fix the links can be given, but I expect the problem to be solved not later than 24 hours from now. Sorry for the inconvenience.

kerberizer commented on 2015-12-06 14:17

Could I please ask those of you who build the packages themselves to test the following very simple patch...

- - - 8 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

diff --git a/PKGBUILD b/PKGBUILD
index eac2328..e1c8456 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -155,6 +155,8 @@ build() {
-DLLVM_BINUTILS_INCDIR:PATH=/usr/include \
"../${_pkgname}"

+ make
+
# Must run this target independently, or else docs/cmake_install.cmake will fail.
# Also, we must check that there isn't an incompatible llvm-ocaml package installed,
# or else the build will fail with "inconsistent assumptions over interface" errors.
@@ -166,8 +168,6 @@ build() {
exit 1
}
make ocaml_doc
-
- make
}

package_llvm-svn() {

- - - 8 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

When I took over the maintainership, make was failing unless the 'ocaml_doc' target had been processed in advance. However, this doesn't quite make sense and I suspect it must have been a transient problem. Several days ago I switched the targets on the system that builds the packages for the binary repo and everything seems to be working fine. In fact, a random error that had previously occurred with building documentation also vanished (which is what I expected and actually why I tested this in the first place).

I'll appreciate your feedback, because there still might be some corner cases where the original problem occurs.

HyperArch commented on 2015-11-14 22:27

@kerberizer Thanks man, issue resolved. Your a king amongst men :)

kerberizer commented on 2015-11-14 19:53

[NOTICE] Yet another fix due to upstream changes in the Clang Static Analyzer (clang-analyzer-svn). The issue reported by @ronoverdrive should be solved now.

kerberizer commented on 2015-11-14 17:04

@ronoverdrive, thanks! There have again been changes upstream in the Clang Static Analyzer install logic. I'll look into it later this evening (UTC+2h). These incremental changes, some of which then also need fixing even upstream, are beginning to get on my nerves, to be honest. Sorry for the inconvenience.

ronoverdrive commented on 2015-11-14 13:45

Getting the following error message preventing me from finishing it:

mv: cannot stat '/tmp/yaourt-tmp-ronoverdrive/aur-llvm-svn/pkg/clang-svn/usr/bin/Reporter.py':No such file or directory
mv: cannot stat '/tmp/yaourt-tmp-ronoverdrive/aur-llvm-svn/pkg/clang-svn/usr/bin/ScanView.py':No such file or directory
mv: cannot stat '/tmp/yaourt-tmp-ronoverdrive/aur-llvm-svn/pkg/clang-svn/usr/bin/startfile.py':No such file or directory

kerberizer commented on 2015-11-13 12:57

[NOTICE] Another fix due to upstream changes in the Clang Static Analyzer (clang-analyzer-svn) has been pushed.

kerberizer commented on 2015-11-09 23:38

[NOTICE] The PKGBUILD has been updated to reflect the changes from r252474 and r252489 in upstream. Using an old PKGBUILD will lead to errors like this:

error: failed to commit transaction (conflicting files)
/usr/bin/scan-build exists in both 'clang-svn' and 'clang-analyzer-svn'
/usr/bin/scan-view exists in both 'clang-svn' and 'clang-analyzer-svn'
/usr/share/man/man1/scan-build.1.gz exists in both 'clang-svn' and 'clang-analyzer-svn'

The changes affect the Clang Static Analyzer (clang-analyzer-svn). I'd like to ask all people who use it to check if everything works as expected. If you encounter any problems, please let me know.

kerberizer commented on 2015-11-05 16:11

Also, please note that the libLTO.so version symlinks are not installed any more.

kerberizer commented on 2015-11-05 15:51

[NOTICE] The PKGBUILD has been updated to reflect the changes from r251411 and r252093 in upstream. Using an old PKGBUILD will lead to errors like this:

error: failed to commit transaction (conflicting files)
/usr/lib/libLLVM-3.8.0svn.so exists in both 'llvm-libs-svn' and 'llvm-svn'
/usr/lib/libLLVM-3.8svn.so exists in both 'llvm-libs-svn' and 'llvm-svn'

kerberizer commented on 2015-10-22 09:35

[NOTICE] The fix for the clang-tools-extra build has been accepted upstream as r251001. The package has been updated accordingly too.

kerberizer commented on 2015-10-21 12:51

[NOTICE] clang-tools-extra build should be fixed now

I've also submitted the fix upstream: http://reviews.llvm.org/D13936

kerberizer commented on 2015-10-21 11:13

[WARNING] clang-tools-extra build fails

Due to recent changes in the CMake logic, building of clang-tools-extra currently fails. I'm looking into it. Please note that because this is the last package to be built, all other packages are built correctly.

kerberizer commented on 2015-10-10 16:13

[NOTICE] Shared library fixed

The critical bug with LLVM not exporting the expected symbols seems to have been fixed completely upstream, so I've removed the last custom patch. Keep this in mind if you notice any "undefined reference" errors.

References:
* https://github.com/kerberizer/llvm-svn/issues/2
* https://llvm.org/bugs/show_bug.cgi?id=24157
* http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-shlib/CMakeLists.txt?r1=246918&r2=249862&diff_format=h

kerberizer commented on 2015-10-09 11:10

[HEADS UP] Users of `llvm-svn`, `mesa-git` and AMD video cards MUST recompile Mesa

If ALL of the following are true for you:
* you use an AMD video card with open source drivers,
* you use `{lib32-,}mesa-git` from AUR,
* you use `{lib32-,}llvm-svn` from AUR,
* you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo,
then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use) due to a recent change in the LLVM shared library.

If Mesa is not recompiled, with the new llvm-svn packages you'll most likely face errors like this:

gbm: Last dlopen error: /usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: _ZN4llvm21SymbolTableListTraitsINS_11InstructionENS_10BasicBlockEE13addNodeToListEPS1_

Please note that for the AMD open source drivers recompiling Mesa on every LLVM upgrade is a good practice, even though most of the time it might not be strictly necessary.

kerberizer commented on 2015-10-01 09:15

@JackM, I'm very reluctant to make this switch right now, because in my view it will actually be detrimental to the users. The reason is that the SSL/TLS configuration on llvm.org is particularly bad. Just look at what the Qualys SSL tester gives as a result: F(ail) with lots and lots of severe problems.

https://www.ssllabs.com/ssltest/analyze.html?d=llvm.org

As a security officer, I've learned to always consider a false sense of security as a much worse option than no security at all. I'd rather have the users _know_ that they can fall a victim of, say, man-in-the-middle attack by using a non-encrypted connection, and thus be ready to check the source files validity by other means or at least be wary, rather than having them feel like they have nothing to worry about and then do fall a victim because of a badly configured encryption on the server side on which they have no control.

I understand there might be other views on this issue, and I'd be really glad to hear them.

JackM commented on 2015-09-30 22:53

please change download url htttps


source=(
- "${_pkgname}::svn+http://llvm.org/svn/llvm-project/llvm/trunk"
- 'clang::svn+http://llvm.org/svn/llvm-project/cfe/trunk'
- 'clang-tools-extra::svn+http://llvm.org/svn/llvm-project/clang-tools-extra/trunk'
- 'compiler-rt::svn+http://llvm.org/svn/llvm-project/compiler-rt/trunk'
+ "${_pkgname}::svn+https://llvm.org/svn/llvm-project/llvm/trunk/"
+ 'clang::svn+https://llvm.org/svn/llvm-project/cfe/trunk/'
+ 'clang-tools-extra::svn+https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/'
+ 'compiler-rt::svn+https://llvm.org/svn/llvm-project/compiler-rt/trunk/'

kerberizer commented on 2015-09-22 12:16

Sorry for not replying earlier, guys, but I've been abroad for a couple of days and I'm still catching up with things.

@Meistache, are you still getting your error? As I've mentioned earlier, transient build errors happen from time to time due to the very high commit activity, but they are also very quickly resolved.

@Eriner, it seems that the custom patch for LLVM bug 24157 is somehow not applied in your case. Could you please check if your PKGBUILD is up to date and that the llvm_tools_shlib_CMakeLists.patch does get applied cleanly during prepare(). Without this patch, it's expected to see the errors you report.

Eriner commented on 2015-09-21 05:54

@Meistache try to remove any previous packages installed by llvm-svn and rebuild.

Is anyone else getting this error building mesa-git? https://gist.github.com/Eriner/195b61a1b8a5e0d954a0

The error above seems to only occur when building llvm-svn from source; it does not occur when using your repo, @kerberizer.

I know the recommendation is to build in a clean chroot, but does that really matter if I remove all the related llvm-svn packages? (obviously it does; I'm just ignorant as to why)

Eriner commented on 2015-09-21 05:35

@Meistache try to remove any previous packages installed by llvm-svn and rebuild.

Is anyone else getting this error building mesa-git? https://gist.github.com/Eriner/195b61a1b8a5e0d954a0

Meistache commented on 2015-09-20 22:47

Hello kerb, just can't go through it, any ocaml binding I should check?

[ 31%] Building CXX object lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o
In file included from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineBasicBlock.h:18:0,
from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineDominators.h:19,
from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachinePostDominators.h:18,
from /home/meistache/AUR/llvm-libs-svn/src/llvm/lib/CodeGen/MachinePostDominators.cpp:15:
/home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineInstr.h:321:3: internal compiler error: in set_inherited_value_binding_p, at cp/name-lookup.c:3003
iterator_range<mop_iterator> defs() {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/build.make:1694: recipe for target 'lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o' failed
make[3]: *** [lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o] Error 1
CMakeFiles/Makefile2:871: recipe for target 'lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/all' failed
make[2]: *** [lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/all] Error 2
CMakeFiles/Makefile2:50481: recipe for target 'docs/CMakeFiles/ocaml_doc.dir/rule' failed
make[1]: *** [docs/CMakeFiles/ocaml_doc.dir/rule] Error 2
Makefile:10415: recipe for target 'ocaml_doc' failed
make: *** [ocaml_doc] Error 2

kerberizer commented on 2015-09-09 13:00

[HEADS UP] Missing compiler-rt added and a package group created

* As reported by @guardian, the compiler-rt set of runtime libraries have been missing entirely from the packages. They are part of the official "clang" package in the extra repo, but here I've decided to put them in a separate package, "clang-compiler-rt-svn", as this seems to be the practice upstream.

IMPORTANT: If you use Clang's sanitizer instrumentation or any other feature that requires the compiler-rt libraries, you MUST install the "clang-compiler-rt-svn" package. It'll also be available from the binary repo shortly.

* All packages have now been made part of a group, "llvm-toolchain-svn". This should allow for easy installation of the whole LLVM toolchain, at least for those who use the binary repo. Instead of "pacman -Sy llvm-svn llvm-libs-svn clang-svn bla-bla-bla...", you can now use just "pacman -Sy llvm-toolchain-svn". The only notable exception are the OCaml bindings that, if needed, must still be installed separately.

kerberizer commented on 2015-09-09 10:38

@guardian, good catch, thank you! I'll look into this asap. Meanwhile, if you have an account on GitHub, could you please report the problem there as well?

https://github.com/kerberizer/llvm-svn/issues

On a side note, it seems that a free-text notes field is badly needed for AUR: the information about binary repos, known bugs, where to report new ones, etc. could go there.

guardian commented on 2015-09-09 07:42

I'm not sure it's the proper place to report my issue but I don't recall how I ended up learning about https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn

I installed clang-analyzer-svn-3.8.0svn_r247119-1.

Then I created a simple C program that does nothing in main.c

Then invoking clang -fsanitize=address main.c reports:
/usr/bin/ld: cannot find /usr/bin/../lib/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)

In fact there's no /usr/lib/clang/3.8.0/lib on my system.

kerberizer commented on 2015-09-07 14:22

@yurikoles, I think I got what you had in mind. You want to have the opportunity to build -- with this PKGBUILD -- not just the latest trunk/master, but also specific releases and tagged versions, right? So the "branch" variable that you mention would be set by the user to the desired code and the source URLs in the PKGBUILD would not end in hard-coded "trunk", but "${branch}", correct?

This is quite an interesting idea, indeed. However, I'm also afraid that it isn't going to work that well too. The problem is that building LLVM is not completely straightforward. For example, we used up until very recently some rather dirty tricks to make it export the necessary symbols in the shared library. With the latest changes upstream, we managed to get rid of most of those hacks. But if you try building even the latest release instead of the trunk, then you must __again__ apply those tricks. So should the PKGBUILD contain and apply those hacks -- necessary for earlier code -- or should it not, which is required for trunk?

In other words, the PKGBUILD is tailored __specifically__ to the trunk/master code. It might indeed work if you try building some older code, e.g. a release, but most likely it will fail or, worse yet, will silently produce problematic binaries/libraries. While it would be theoretically possible to support internal logic accounting for the specifics of the countless number of branches and tags that a user might want to build, neither do I have the resources to maintain such a complicated PKGBUILD, nor do I find it particularly efficient from maintainer's point of you. And in the context of AUR, it would be much better to have a separate package for each historic release anyway.

Sorry if I disappoint you, and please do let me know if I haven't got your idea right.

kerberizer commented on 2015-09-06 19:06

A note on LLDB.

The official llvm set of packages includes lldb, and several days ago I actually tried adding it here -- not realizing that there is already an independent lldb-svn package here on AUR. I've contacted its maintainers and asked them if they would agree merging their package into llvm-svn, as I think this would allow for much greater consistency and even ease of support. I haven't yet received a reply, but I guess they are most likely very busy.

In short, guys, I'd be happy to hear if you want to see LLDB here.

And for those who build the packages yourself and want LLDB, you can use the GitHub repo. There's a branch enh/lldb-svn, which is rebased to master regularly.

https://github.com/kerberizer/llvm-svn/tree/enh/lldb-svn

kerberizer commented on 2015-09-06 18:48

@yurikoles, not sure that I understand your request. Could you please elaborate a bit more?

yurikoles commented on 2015-09-06 15:55

Please extract "trunk" to variable "branch". It may be for example "branches/release_37" or "tags/RELEASE_370/final". I have tested all 3 values.

kerberizer commented on 2015-09-06 11:16

[HEADS UP] Rebuild required

I've committed the change that should fix the shared library breakage. This might require some action on your side, namely:

* If you build the packages yourself and have last rebuilt them more recently than 08:30 AM UTC yesterday, Sept 5th, please do rebuild them again now.

* If you use the binary repo and have last updated your packages from the repo more recently than 09:00 AM UTC yesterday, Sept 5th, please wait until about 11:45 AM UTC today, Sept 6th (half an hour from now; the new packages are still being built), and update again.

As usual, please let me know if you find any problems, and especially if they are of the "undefined reference" type when linking to libLLVM, please report them here: https://github.com/kerberizer/llvm-svn/issues/2

kerberizer commented on 2015-09-06 09:48

For those curious enough, this is the commit that breaks our build, due to the changes to tools/llvm-shlib/CMakeLists.txt, which we parse in order to determine which components we want exported from the shared lib (and which, in turn, we make because of the bug in exporting the necessary symbols on Linux).

https://github.com/llvm-mirror/llvm/commit/f5148ebe0ac2e89cf991b7d6e01778bbb8d55034

I'm testing at the moment a changed PKGBUILD that should hopefully produce a working shared lib again. Sorry for any inconvenience.

kerberizer commented on 2015-09-06 09:25

[WARNING] The shared library seems broken at the moment, with many symbols not being exported. I'm looking into this.

kerberizer commented on 2015-09-03 14:53

[NOTICE] Possible instability ahead

Guys, please take note that in the next days I'll be working on a probably major rework of the PKGBUILD. The reason is that the critical bug with LLVM not exporting the expected symbols has (likely) been fixed upstream at last. This means that the bunch of "awk-ward" dirty tricks currently in the PKGBUILD is probably not needed any more, but I'll have to test this thoroughly. I'll try to make sure that the PKGBUILD stays stable, but just be warned in advance. I'll also post the usual "heads up" once any such changes get committed here.

References:
* https://github.com/kerberizer/llvm-svn/issues/2
* https://llvm.org/bugs/show_bug.cgi?id=24157
* https://github.com/llvm-mirror/llvm/commit/10add60748226d67d3a1e4d1a8175f798a053708

kerberizer commented on 2015-09-02 21:47

@Eriner, not sure if that could've been the case here, but sometimes various transient build errors happen just because that's the master branch, with all development constantly going on, and, though rarely, commits do happen to break things, even that badly. They are also usually fixed very quickly, so just waiting an hour or so and building again from fresh source code is all that is needed.

Eriner commented on 2015-09-02 20:15

Ah, after completely removing the svn repo and rebuilding it seems to have fixed itself. So if anyone gets the same error as below, remove your llvm-svn folder, git pull, rebuild.

Eriner commented on 2015-09-02 20:08

Anyone getting errors like this? https://gist.github.com/Eriner/30274ab4da191d06724c

kerberizer commented on 2015-09-02 10:36

[NOTICE] The patch to detect incompatible OCaml bindings has just been commited...

https://aur.archlinux.org/cgit/aur.git/commit/?h=llvm-svn&id=62e08fbe60743ed35f8e3d34f18644be58d90f25

kerberizer commented on 2015-09-01 21:41

@agm28011997, I'm glad that you've solved the problems with LLVM and Mesa, and sorry that I cannot offer any advice on Supertuxkart, since I've never played that game. The best place to ask for further help might be the Arch forums...

https://bbs.archlinux.org/viewforum.php?id=32

...and the forum of the game itself...

http://forum.freegamedev.net/viewforum.php?f=16

agm28011997 commented on 2015-09-01 21:20

Now I got compiled svn llvm and mesa git thanks for the help and I tried compiling mesa because a game (supertuxkart) functions normally in wine, windows and ubuntu but in arch the textures are very dark and I wanted to know why, now the game function like before, I don't know how to play the game normal in linux

kerberizer commented on 2015-09-01 20:27

@agm28011997, I'm not sure if I understand you correctly, but it seems as if you tried building from source the official package, which I have no control over.

In any case, since you obviously want to use mesa-git, I'd suggest to you two alternatives:

1) The easiest thing is to simply use the binary repo that I provide...

https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn

It saves you all the trouble with building the packages yourself, makes for almost instant and always current updates (the packages are rebuilt against the latest SVN code every 6 hours), and even helps the environment. ;)

2) If you don't trust the repo (which is perfectly fine and understandable) or have other reasons to build the packages yourself, try to familiarize yourself with the process of building in a clean chroot...

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

agm28011997 commented on 2015-09-01 20:05

Sorry, I haven't read this comments and the problem have been fixed with the installing of older llvm and clang packages of the repository or arch, clang and llvm in version 3.5, the 3.6 version have problems for compile clang and llvm svn

kerberizer commented on 2015-09-01 15:35

Here's the promised test for incompatible OCaml bindings...

https://github.com/kerberizer/llvm-svn/commit/59a1f4934baf13aa479a744c91ee668f8c456359

I'll be glad to hear comments or suggestions before committing it to AUR as well.

kerberizer commented on 2015-09-01 08:33

@agm28011997, please see this issue...

https://github.com/kerberizer/llvm-svn/issues/4

In short, either uninstall any previously installed llvm-ocaml package before building, or, much preferably, build in a clean chroot.

I'll consider implementing some test for the incompatible OCaml bindings, but the advice on using clean build environment still stands.

agm28011997 commented on 2015-09-01 01:28

I have problems with the compile of this package, this is the output:
92%] Building OCaml library llvm_analysis
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
[ 92%] Building OCaml documentation for llvm_analysis
Copying OCaml library component llvm_analysis.cma to intermediate area
Copying OCaml library component libllvm_analysis.a to intermediate area
Copying OCaml library component llvm_analysis.cmxa to intermediate area
Copying OCaml library component llvm_analysis.a to intermediate area
Copying OCaml library component llvm_analysis.cmi to intermediate area
Copying OCaml library component llvm_analysis.cmx to intermediate area
[ 92%] Built target ocaml_llvm_analysis
Scanning dependencies of target ocaml_llvm_AArch64
[ 92%] Building OCaml stub object file AArch64_ocaml.o
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
[ 92%] Building OCaml library llvm_AArch64
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
[ 92%] Building OCaml documentation for llvm_AArch64
Copying OCaml library component llvm_AArch64.cma to intermediate area
[ 92%] Building CXX object lib/Target/XCore/CMakeFiles/LLVMXCoreCodeGen.dir/XCoreFrameToArgsOffsetElim.cpp.o
Copying OCaml library component libllvm_AArch64.a to intermediate area
Copying OCaml library component llvm_AArch64.cmxa to intermediate area
Copying OCaml library component llvm_AArch64.a to intermediate area
Copying OCaml library component llvm_AArch64.cmi to intermediate area
Copying OCaml library component llvm_AArch64.cmx to intermediate area
[ 92%] Built target ocaml_llvm_AArch64
Scanning dependencies of target ocaml_llvm_AMDGPU
[ 92%] Building OCaml stub object file AMDGPU_ocaml.o
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
[ 92%] Building OCaml library llvm_AMDGPU
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
[ 92%] Building OCaml documentation for llvm_AMDGPU
Scanning dependencies of target ocaml_llvm_ARM
[ 92%] Building OCaml stub object file ARM_ocaml.o
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_AMDGPU.cma to intermediate area
Scanning dependencies of target ocaml_llvm_BPF
Copying OCaml library component libllvm_AMDGPU.a to intermediate area
[ 92%] Building OCaml stub object file BPF_ocaml.o
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_AMDGPU.cmxa to intermediate area
Copying OCaml library component llvm_AMDGPU.a to intermediate area
[ 92%] Building OCaml library llvm_ARM
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_AMDGPU.cmi to intermediate area
[ 92%] Building OCaml library llvm_BPF
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_AMDGPU.cmx to intermediate area
[ 92%] Built target ocaml_llvm_AMDGPU
Scanning dependencies of target ocaml_llvm_Hexagon
[ 92%] Building OCaml stub object file Hexagon_ocaml.o
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
[ 92%] Building OCaml documentation for llvm_ARM
[ 92%] Building OCaml library llvm_Hexagon
[ 92%] Building OCaml documentation for llvm_BPF
Copying OCaml library component llvm_ARM.cma to intermediate area
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component libllvm_ARM.a to intermediate area
Copying OCaml library component llvm_BPF.cma to intermediate area
Copying OCaml library component llvm_ARM.cmxa to intermediate area
Copying OCaml library component llvm_ARM.a to intermediate area
Copying OCaml library component libllvm_BPF.a to intermediate area
Copying OCaml library component llvm_ARM.cmi to intermediate area
Copying OCaml library component llvm_BPF.cmxa to intermediate area
Copying OCaml library component llvm_BPF.a to intermediate area
Copying OCaml library component llvm_ARM.cmx to intermediate area
Copying OCaml library component llvm_BPF.cmi to intermediate area
[ 92%] Built target ocaml_llvm_ARM
Scanning dependencies of target ocaml_llvm_Mips
Copying OCaml library component llvm_BPF.cmx to intermediate area
[ 95%] Building OCaml stub object file Mips_ocaml.o
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
[ 95%] Built target ocaml_llvm_BPF
[ 95%] Building OCaml documentation for llvm_Hexagon
Scanning dependencies of target ocaml_llvm_MSP430
[ 95%] Building OCaml stub object file MSP430_ocaml.o
Copying OCaml library component llvm_Hexagon.cma to intermediate area
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component libllvm_Hexagon.a to intermediate area
[ 95%] Building OCaml library llvm_Mips
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_Hexagon.cmxa to intermediate area
[ 95%] Building OCaml library llvm_MSP430
Copying OCaml library component llvm_Hexagon.a to intermediate area
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_Hexagon.cmi to intermediate area
Copying OCaml library component llvm_Hexagon.cmx to intermediate area
[ 95%] Built target ocaml_llvm_Hexagon
Scanning dependencies of target ocaml_llvm_NVPTX
[ 95%] Building OCaml stub object file NVPTX_ocaml.o
[ 95%] Building OCaml documentation for llvm_Mips
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_Mips.cma to intermediate area
Copying OCaml library component libllvm_Mips.a to intermediate area
[ 95%] Building OCaml library llvm_NVPTX
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_Mips.cmxa to intermediate area
Copying OCaml library component llvm_Mips.a to intermediate area
[ 95%] Building OCaml documentation for llvm_MSP430
Copying OCaml library component llvm_Mips.cmi to intermediate area
Copying OCaml library component llvm_MSP430.cma to intermediate area
Copying OCaml library component llvm_Mips.cmx to intermediate area
Copying OCaml library component libllvm_MSP430.a to intermediate area
[ 95%] Built target ocaml_llvm_Mips
Copying OCaml library component llvm_MSP430.cmxa to intermediate area
Scanning dependencies of target ocaml_llvm_PowerPC
[ 95%] Building OCaml stub object file PowerPC_ocaml.o
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_MSP430.a to intermediate area
Copying OCaml library component llvm_MSP430.cmi to intermediate area
Copying OCaml library component llvm_MSP430.cmx to intermediate area
[ 95%] Building OCaml documentation for llvm_NVPTX
[ 95%] Built target ocaml_llvm_MSP430
[ 95%] Building OCaml library llvm_PowerPC
Scanning dependencies of target ocaml_llvm_Sparc
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
[ 95%] Building OCaml stub object file Sparc_ocaml.o
Copying OCaml library component llvm_NVPTX.cma to intermediate area
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component libllvm_NVPTX.a to intermediate area
Copying OCaml library component llvm_NVPTX.cmxa to intermediate area
Copying OCaml library component llvm_NVPTX.a to intermediate area
[ 95%] Building OCaml library llvm_Sparc
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_NVPTX.cmi to intermediate area
Copying OCaml library component llvm_NVPTX.cmx to intermediate area
[ 95%] Built target ocaml_llvm_NVPTX
Scanning dependencies of target ocaml_llvm_SystemZ
[ 95%] Building OCaml stub object file SystemZ_ocaml.o
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
[ 95%] Building OCaml documentation for llvm_PowerPC
Copying OCaml library component llvm_PowerPC.cma to intermediate area
[ 95%] Building OCaml library llvm_SystemZ
Copying OCaml library component libllvm_PowerPC.a to intermediate area
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_PowerPC.cmxa to intermediate area
[ 95%] Building OCaml documentation for llvm_Sparc
Copying OCaml library component llvm_PowerPC.a to intermediate area
Copying OCaml library component llvm_Sparc.cma to intermediate area
Copying OCaml library component libllvm_Sparc.a to intermediate area
Copying OCaml library component llvm_PowerPC.cmi to intermediate area
Copying OCaml library component llvm_PowerPC.cmx to intermediate area
Copying OCaml library component llvm_Sparc.cmxa to intermediate area
[ 95%] Built target ocaml_llvm_PowerPC
Scanning dependencies of target ocaml_llvm_X86
Copying OCaml library component llvm_Sparc.a to intermediate area
[ 95%] Building OCaml stub object file X86_ocaml.o
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_Sparc.cmi to intermediate area
Copying OCaml library component llvm_Sparc.cmx to intermediate area
[ 95%] Built target ocaml_llvm_Sparc
Scanning dependencies of target ocaml_llvm_bitreader
[ 95%] Building OCaml documentation for llvm_SystemZ
[ 95%] Building OCaml library llvm_X86
[ 95%] Copying bitreader_ocaml.c to build area
Copying OCaml library component llvm_SystemZ.cma to intermediate area
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
[ 95%] Copying llvm_bitreader.mli to build area
Copying OCaml library component libllvm_SystemZ.a to intermediate area
[ 95%] Copying llvm_bitreader.ml to build area
Copying OCaml library component llvm_SystemZ.cmxa to intermediate area
[ 95%] Building OCaml stub object file bitreader_ocaml.o
Copying OCaml library component llvm_SystemZ.a to intermediate area
Copying OCaml library component llvm_SystemZ.cmi to intermediate area
Copying OCaml library component llvm_SystemZ.cmx to intermediate area
[ 95%] Built target ocaml_llvm_SystemZ
[ 95%] Building OCaml library llvm_bitreader
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Scanning dependencies of target ocaml_llvm_bitwriter
[ 95%] Building OCaml documentation for llvm_X86
[ 95%] Copying bitwriter_ocaml.c to build area
Copying OCaml library component llvm_X86.cma to intermediate area
[ 97%] Copying llvm_bitwriter.mli to build area
Copying OCaml library component libllvm_X86.a to intermediate area
Copying OCaml library component llvm_X86.cmxa to intermediate area
[ 97%] Copying llvm_bitwriter.ml to build area
Copying OCaml library component llvm_X86.a to intermediate area
[ 97%] Building OCaml stub object file bitwriter_ocaml.o
Copying OCaml library component llvm_X86.cmi to intermediate area
Copying OCaml library component llvm_X86.cmx to intermediate area
[ 97%] Built target ocaml_llvm_X86
[ 97%] Building OCaml documentation for llvm_bitreader
Scanning dependencies of target ocaml_llvm_irreader
[ 97%] Copying irreader_ocaml.c to build area
Copying OCaml library component llvm_bitreader.cma to intermediate area
[ 97%] Building OCaml library llvm_bitwriter
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Copying OCaml library component libllvm_bitreader.a to intermediate area
[ 97%] Copying llvm_irreader.mli to build area
[ 97%] Copying llvm_irreader.ml to build area
Copying OCaml library component llvm_bitreader.cmxa to intermediate area
[ 97%] Building OCaml stub object file irreader_ocaml.o
Copying OCaml library component llvm_bitreader.a to intermediate area
Copying OCaml library component llvm_bitreader.cmi to intermediate area
Copying OCaml library component llvm_bitreader.cmx to intermediate area
[ 97%] Built target ocaml_llvm_bitreader
Scanning dependencies of target ocaml_llvm_linker
[ 97%] Building OCaml library llvm_irreader
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
[ 97%] Copying linker_ocaml.c to build area
[ 97%] Copying llvm_linker.mli to build area
[ 97%] Building OCaml documentation for llvm_bitwriter
[ 97%] Copying llvm_linker.ml to build area
[ 97%] Building OCaml stub object file linker_ocaml.o
Copying OCaml library component llvm_bitwriter.cma to intermediate area
Copying OCaml library component libllvm_bitwriter.a to intermediate area
Copying OCaml library component llvm_bitwriter.cmxa to intermediate area
Copying OCaml library component llvm_bitwriter.a to intermediate area
[ 97%] Building OCaml library llvm_linker
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Copying OCaml library component llvm_bitwriter.cmi to intermediate area
Copying OCaml library component llvm_bitwriter.cmx to intermediate area
[ 97%] Building OCaml documentation for llvm_irreader
[ 97%] Built target ocaml_llvm_bitwriter
Copying OCaml library component llvm_irreader.cma to intermediate area
Scanning dependencies of target ocaml_llvm_ipo
[ 97%] Copying ipo_ocaml.c to build area
Copying OCaml library component libllvm_irreader.a to intermediate area
[ 97%] Copying llvm_ipo.mli to build area
Copying OCaml library component llvm_irreader.cmxa to intermediate area
[ 97%] Copying llvm_ipo.ml to build area
Copying OCaml library component llvm_irreader.a to intermediate area
Copying OCaml library component llvm_irreader.cmi to intermediate area
[ 97%] Building OCaml stub object file ipo_ocaml.o
Copying OCaml library component llvm_irreader.cmx to intermediate area
[ 97%] Building OCaml documentation for llvm_linker
[ 97%] Built target ocaml_llvm_irreader
Copying OCaml library component llvm_linker.cma to intermediate area
Scanning dependencies of target ocaml_llvm_passmgr_builder
Copying OCaml library component libllvm_linker.a to intermediate area
[ 97%] Copying passmgr_builder_ocaml.c to build area
Copying OCaml library component llvm_linker.cmxa to intermediate area
[ 97%] Building OCaml library llvm_ipo
[ 97%] Copying llvm_passmgr_builder.mli to build area
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Copying OCaml library component llvm_linker.a to intermediate area
Copying OCaml library component llvm_linker.cmi to intermediate area
[ 97%] Copying llvm_passmgr_builder.ml to build area
[ 97%] Building OCaml stub object file passmgr_builder_ocaml.o
Copying OCaml library component llvm_linker.cmx to intermediate area
[ 97%] Built target ocaml_llvm_linker
Scanning dependencies of target ocaml_llvm_scalar_opts
[100%] Copying scalar_opts_ocaml.c to build area
[100%] Copying llvm_scalar_opts.mli to build area
[100%] Copying llvm_scalar_opts.ml to build area
[100%] Building OCaml stub object file scalar_opts_ocaml.o
[100%] Building OCaml library llvm_passmgr_builder
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
[100%] Building OCaml documentation for llvm_ipo
Copying OCaml library component llvm_ipo.cma to intermediate area
[100%] Building OCaml library llvm_scalar_opts
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Copying OCaml library component libllvm_ipo.a to intermediate area
Copying OCaml library component llvm_ipo.cmxa to intermediate area
Copying OCaml library component llvm_ipo.a to intermediate area
Copying OCaml library component llvm_ipo.cmi to intermediate area
Copying OCaml library component llvm_ipo.cmx to intermediate area
[100%] Building OCaml documentation for llvm_passmgr_builder
[100%] Built target ocaml_llvm_ipo
Scanning dependencies of target ocaml_llvm_transform_utils
[100%] Copying transform_utils_ocaml.c to build area
Copying OCaml library component llvm_passmgr_builder.cma to intermediate area
Copying OCaml library component libllvm_passmgr_builder.a to intermediate area
[100%] Copying llvm_transform_utils.mli to build area
Copying OCaml library component llvm_passmgr_builder.cmxa to intermediate area
[100%] Copying llvm_transform_utils.ml to build area
[100%] Building OCaml documentation for llvm_scalar_opts
Copying OCaml library component llvm_passmgr_builder.a to intermediate area
[100%] Building OCaml stub object file transform_utils_ocaml.o
Copying OCaml library component llvm_scalar_opts.cma to intermediate area
Copying OCaml library component llvm_passmgr_builder.cmi to intermediate area
Copying OCaml library component libllvm_scalar_opts.a to intermediate area
Copying OCaml library component llvm_passmgr_builder.cmx to intermediate area
Copying OCaml library component llvm_scalar_opts.cmxa to intermediate area
[100%] Built target ocaml_llvm_passmgr_builder
Scanning dependencies of target ocaml_llvm_vectorize
Copying OCaml library component llvm_scalar_opts.a to intermediate area
[100%] Building OCaml library llvm_transform_utils
[100%] Copying vectorize_ocaml.c to build area
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Copying OCaml library component llvm_scalar_opts.cmi to intermediate area
Copying OCaml library component llvm_scalar_opts.cmx to intermediate area
[100%] Copying llvm_vectorize.mli to build area
[100%] Copying llvm_vectorize.ml to build area
[100%] Built target ocaml_llvm_scalar_opts
[100%] Building OCaml stub object file vectorize_ocaml.o
Scanning dependencies of target ocaml_llvm_target
[100%] Linking CXX static library ../../libLLVMXCoreCodeGen.a
[100%] Copying target_ocaml.c to build area
[100%] Copying llvm_target.mli to build area
[100%] Building OCaml library llvm_vectorize
[100%] Copying llvm_target.ml to build area
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
[100%] Building OCaml documentation for llvm_transform_utils
[100%] Built target LLVMXCoreCodeGen
[100%] Building OCaml stub object file target_ocaml.o
Scanning dependencies of target ocaml_llvm_all_backends
Copying OCaml library component llvm_transform_utils.cma to intermediate area
[100%] Copying all_backends_ocaml.c to build area
Copying OCaml library component libllvm_transform_utils.a to intermediate area
[100%] Copying llvm_all_backends.mli to build area
Copying OCaml library component llvm_transform_utils.cmxa to intermediate area
[100%] Copying llvm_all_backends.ml to build area
Copying OCaml library component llvm_transform_utils.a to intermediate area
[100%] Building OCaml stub object file all_backends_ocaml.o
Copying OCaml library component llvm_transform_utils.cmi to intermediate area
Copying OCaml library component llvm_transform_utils.cmx to intermediate area
[100%] Building OCaml documentation for llvm_vectorize
[100%] Built target ocaml_llvm_transform_utils
Scanning dependencies of target ocaml_llvm_XCore
[100%] Building OCaml library llvm_target
[100%] Building OCaml library llvm_all_backends
Copying OCaml library component llvm_vectorize.cma to intermediate area
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
[100%] Building OCaml stub object file XCore_ocaml.o
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm
Copying OCaml library component libllvm_vectorize.a to intermediate area
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_X86.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
Copying OCaml library component llvm_vectorize.cmxa to intermediate area
Copying OCaml library component llvm_vectorize.a to intermediate area
Copying OCaml library component llvm_vectorize.cmi to intermediate area
Copying OCaml library component llvm_vectorize.cmx to intermediate area
[100%] Building OCaml library llvm_XCore
findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_X86.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, .
findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, .
[100%] Built target ocaml_llvm_vectorize
[100%] Building OCaml documentation for llvm_all_backends
Copying OCaml library component llvm_all_backends.cma to intermediate area
Copying OCaml library component libllvm_all_backends.a to intermediate area
[100%] Building OCaml documentation for llvm_target
Copying OCaml library component llvm_all_backends.cmxa to intermediate area
Copying OCaml library component llvm_all_backends.a to intermediate area
Copying OCaml library component llvm_target.cma to intermediate area
Copying OCaml library component llvm_all_backends.cmi to intermediate area
Copying OCaml library component libllvm_target.a to intermediate area
Copying OCaml library component llvm_all_backends.cmx to intermediate area
Copying OCaml library component llvm_target.cmxa to intermediate area
[100%] Built target ocaml_llvm_all_backends
Copying OCaml library component llvm_target.a to intermediate area
[100%] Building OCaml documentation for llvm_XCore
Copying OCaml library component llvm_target.cmi to intermediate area
Copying OCaml library component llvm_XCore.cma to intermediate area
Copying OCaml library component llvm_target.cmx to intermediate area
Copying OCaml library component libllvm_XCore.a to intermediate area
[100%] Built target ocaml_llvm_target
Copying OCaml library component llvm_XCore.cmxa to intermediate area
Scanning dependencies of target ocaml_llvm_executionengine
Copying OCaml library component llvm_XCore.a to intermediate area
[100%] Copying llvm_executionengine.mli to build area
[100%] Copying executionengine_ocaml.c to build area
[100%] Copying llvm_executionengine.ml to build area
Copying OCaml library component llvm_XCore.cmi to intermediate area
[100%] Building OCaml stub object file executionengine_ocaml.o
Copying OCaml library component llvm_XCore.cmx to intermediate area
[100%] Built target ocaml_llvm_XCore
[100%] Building OCaml library llvm_executionengine
findlib: [WARNING] Interface llvm.cmi occurs in several directories: /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm, /usr/lib/ocaml
findlib: [WARNING] Interface llvm_target.cmi occurs in several directories: /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/target, /usr/lib/ocaml
[100%] Building OCaml documentation for llvm_executionengine
File "/tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/executionengine/llvm_executionengine.ml", line 1:
Error: The files /usr/lib/ocaml/llvm_target.cmi and llvm_executionengine.cmi
make inconsistent assumptions over interface Llvm_target
1 error(s) encountered
bindings/ocaml/executionengine/CMakeFiles/ocaml_llvm_executionengine.dir/build.make:104: fallo en las instrucciones para el objetivo 'bindings/ocaml/executionengine/llvm_executionengine.odoc'
make[3]: *** [bindings/ocaml/executionengine/llvm_executionengine.odoc] Error 1
make[3]: *** Se borra el archivo 'bindings/ocaml/executionengine/llvm_executionengine.odoc'
CMakeFiles/Makefile2:13461: fallo en las instrucciones para el objetivo 'bindings/ocaml/executionengine/CMakeFiles/ocaml_llvm_executionengine.dir/all'
make[2]: *** [bindings/ocaml/executionengine/CMakeFiles/ocaml_llvm_executionengine.dir/all] Error 2
CMakeFiles/Makefile2:51857: fallo en las instrucciones para el objetivo 'docs/CMakeFiles/ocaml_doc.dir/rule'
make[1]: *** [docs/CMakeFiles/ocaml_doc.dir/rule] Error 2
Makefile:10792: fallo en las instrucciones para el objetivo 'ocaml_doc'
make: *** [ocaml_doc] Error 2
==> ERROR: Se produjo un fallo en build().

I don't know why

kerberizer commented on 2015-08-22 12:18

@Lone_Wolf
> I'll be testing aur mesa-git against this package now.
Thanks! Let me know if you face any problems.

> Add a note about the build environment you use for it
Good point, added (TL;DR: clean chroot, latest NON-testing repos).
https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn

If packages built against {,community-,multilib-}testing are required, let me know, and I'll look into it.

Lone_Wolf commented on 2015-08-22 09:28

I'll be testing aur mesa-git against this package now.

A few comments about the binary repo :
Add a note about the build environment you use for it :
clean chroot ?
building against latest core/extra/community repos, against testing repos or against a snapshot (like suse OBS does ).

kerberizer commented on 2015-08-19 09:03

I probably should've announced that the builds in the binary repo are now automatic, every 6 hours starting from 03:00 AM UTC. It's probably an overkill user-wise, but considering the commit activity, if something breaks badly and consistently, this should in theory help narrow down the possible reasons.

Please let me know if you have any thoughts on this, e.g. if someone is pissed off with the constant updates and would prefer an e.g. daily or even weekly repo (that's not hard to set up at all).

BTW, don't forget that you can use GitHub if you have specific issues...

https://github.com/kerberizer/llvm-svn/issues

...and especially if you want to suggest a patch...

https://github.com/kerberizer/llvm-svn/pulls

kerberizer commented on 2015-08-09 03:01

[NEWS] Binary repo available

For those who prefer prebuilt, binary packages, there's a repo available now...

https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn

I'm thinking of updating this repo daily (if possible), probably creating along the road other repos that'll get updated less often (e.g. weekly, monthly). Let me know if you have any thoughts on this.

kerberizer commented on 2015-08-06 20:39

[HEADS UP] Manual intervention required: version scheme change

The new PKGBUILD that I'll be pushing shortly uses a different version scheme. Instead of only the SVN revision number, it also includes the LLVM version number itself. For example, instead of version 241875-1, the new package will have version 3.8.0svn_r244189-1. This is meant to not only help users easier determine what LLVM version they are using, but also to be as close to the output of `llvm-config --version` as possible.

However, because of how Pacman treats version numbers, it and likely all AUR helpers that you may be using (e.g. Yaourt) will recognize the new version as a _downgrade_. YOU WILL NEED TO ACCEPT OR FORCE THIS "DOWNGRADE". This will happen only once; all subsequent upgrades should proceed as expected. Sorry for this inconvenience.

Technically, it would've been possible to avoid the issue altogether by using the "epoch" variable, but I feel the case doesn't call for such radical measures.

Please note as well that the new version will build the Ocaml bindings by default.

kerberizer commented on 2015-08-05 14:35

Guys, since @Krejzi has stepped down as a maintainer (once again many thanks for all his work on this!), I might try to take his place. However, if there are more knowledgeable and experienced in LLVM and AUR people around, who would be willing to step in, that will certainly be a better choice. If you feel like it, please don't hesitate to raise your hand. ;)

If no one else volunteers, I'll take over, at least temporarily, this and the lib32- package, though I won't be able to fix the latter immediately.

Meanwhile, I'd like to ask once again everyone to test the PKGBUILD on Github (the link is in my previous comment below). Although I think I've managed to fix the most blatant bugs (i.e. Mesa not building), I'm pretty sure there might be others as well. Any comments and suggestions will be more than welcome.

kerberizer commented on 2015-08-01 20:35

Guys, @Krejzi,

I've made a modified PKGBUILD that uses cmake instead of autotools, since this, from what I could gather, is the preferred method of building LLVM/Clang nowadays. That way, the out-of-source build error is also solved.

https://github.com/kerberizer/llvm-svn

The PKGBUILD definitely needs more refinement and efficiency improvements and might even have an error or two (e.g. placing some files in wrong places), but at least it seems to work well enough. Feel free to test it; any comments and suggestions will be more than welcome.

@Krejzi, if you think it might be helpful, feel free to merge it back here. Speaking of which, I really appreciate your and that of the other contributors work. Thank you!

Madotsuki commented on 2015-07-31 18:28

There was a big update with Mesa and OpenGL 4 recently, you might want to update the regular AUR version of this package.

MaplySyrup commented on 2015-07-26 02:04

This PKGBUILD no longer works as LLVM ./configure no longer allows it to be done in the main dir, you have to create a build dir and configure from there.
Also this changes all the mv commands.

Krejzi commented on 2015-07-14 18:58

Should be fixed now.

alaviss commented on 2015-07-08 03:18

This package now requires out-of-source build

configure: error: In-source builds are not allowed. Please configure from a separate build directory!

SpotlightKid commented on 2015-04-14 16:23

My sincere apologies, I was posting on the wrong package page and also flagged it as out-of-date wrongly. Please disregard and remove the flag.

SpotlightKid commented on 2015-04-14 16:22

Apparently llvm 3.6 (which is installed on my system now) has removed JIT.h and building faust2-git fails with:

In file included from generator/llvm/llvm_code_container.hh:26:0,
from generator/llvm/llvm_code_container.cpp:26:
generator/llvm/llvm_instructions.hh:55:38: fatal error: llvm/ExecutionEngine/JIT.h: No such file or directory
#include <llvm/ExecutionEngine/JIT.h>
^
compilation terminated.

The package should therefore depend on llvm35 now.

SpotlightKid commented on 2015-04-14 16:21

Apparently llvm 3.6 (which is installed on my system now) has removed JIT.h and building faust2-git fails with:

In file included from generator/llvm/llvm_code_container.hh:26:0,
from generator/llvm/llvm_code_container.cpp:26:
generator/llvm/llvm_instructions.hh:55:38: fatal error: llvm/ExecutionEngine/JIT.h: No such file or directory
#include <llvm/ExecutionEngine/JIT.h>
^
compilation terminated.

The package should therefore depend on llvm32 now.

Krejzi commented on 2015-02-09 12:29

What I said still stands: If you know a way for me to enable what you are asking for, then please write it here.

Krejzi commented on 2015-02-09 12:29

What I said still stands: If you know a way for me to enable what you are asking for, then please write it here.

mizvekov commented on 2015-02-09 10:06

@Krejzi

It does make sense if one needs to statically link them, or if you are developing for bare-metal targets.
Right now I am using clang in place of arm-none-eabi-gcc, and the gcc distribution does include them.

The problem right now as I see it is that the build system doesn't use the just built clang in order to build compiler-rt, so it's not as simple as it should be. This will probably change though, a bug report has been opened for it and they are waiting for patches.

kdj0c commented on 2015-02-06 22:42

I get an error when building documentation:

# Sphinx version: 1.2.3
# Python version: 3.4.2
# Docutils version: 0.12 release
# Jinja2 version: 2.7.3
# Loaded extensions:
# sphinx.ext.oldcmarkup from /usr/lib/python3.4/site-packages/sphinx/ext/oldcmarkup.py
# sphinx.ext.intersphinx from /usr/lib/python3.4/site-packages/sphinx/ext/intersphinx.py
# sphinx.ext.todo from /usr/lib/python3.4/site-packages/sphinx/ext/todo.py
Traceback (most recent call last):
File "/usr/lib/python3.4/site-packages/sphinx/cmdline.py", line 254, in main
app.build(force_all, filenames)
File "/usr/lib/python3.4/site-packages/sphinx/application.py", line 220, in build
self.builder.build_update()
File "/usr/lib/python3.4/site-packages/sphinx/builders/__init__.py", line 209, in build_update
self.build(['__all__'], to_build)
File "/usr/lib/python3.4/site-packages/sphinx/builders/__init__.py", line 234, in build
purple, length):
File "/usr/lib/python3.4/site-packages/sphinx/builders/__init__.py", line 134, in status_iterator
for item in iterable:
File "/usr/lib/python3.4/site-packages/sphinx/environment.py", line 478, in update_generator
self.read_doc(docname, app=app)
File "/usr/lib/python3.4/site-packages/sphinx/environment.py", line 697, in read_doc
pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL)
RuntimeError: maximum recursion depth exceeded while calling a Python object

Krejzi commented on 2015-01-27 19:08

Erm ... Compiler-Rt, (Runtime) is probably meant (as the name says) for running applications and makes no sense to build it for foreign arches. If you however know of a way for me to provide compiler-rt for all the available architectures, I could implement it in this package.

mizvekov commented on 2015-01-23 21:41

This package is missing compiler-rt libs for all arches except x86/x64, even though it's supposed to support all targets.

Krejzi commented on 2015-01-19 15:01

pod2html is part of perl package. If you tampered with the PATH environment variable, make sure you also include perl paths (/usr/bin/core_perl or something like that)

lucastanure commented on 2015-01-19 14:56

make[2]: pod2html: Command not found

make[2]: Entering directory '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools'
pod2html --css=manpage.css --htmlroot=. \
--podpath=. --infile=clang.pod --outfile=/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools/clang.html --title=clang
make[2]: pod2html: Command not found
Makefile:69: recipe for target '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools/clang.html' failed
make[2]: *** [/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools/clang.html] Error 127
rm /tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools//.dir
make[2]: Leaving directory '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools'
/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/Makefile.rules:883: recipe for target 'install' failed
make[1]: *** [install] Error 1
make[1]: Leaving directory '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs'
/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/Makefile.rules:883: recipe for target 'install' failed



schulmar commented on 2015-01-10 12:22

@yan12125: Sorry, I was a bit trigger happy with the merge request. If you want to take over the llvm-toolchain-svn I can send you the last PKGBUILD.

While I concur that the build takes awfully long, I find it unacceptable to duplicate packages over and over again to offer the fastest build time. This goes against modularity.

The best option would be to have makepkg support different packages to be built together in one step. Maybe it does but my knowledge is not sufficient on this.

yan12125 commented on 2015-01-08 18:17

This package provides lldb. I prefer a lldb+llvm bundle rather than splitted packages. It takes more time to build llvm-svn+lldb-svn than to build a single package.

yan12125 commented on 2015-01-08 14:19

This package provides lldb. I prefer a lldb+llvm bundle rather than splitted packages.

schulmar commented on 2015-01-08 11:34

@yan12125: I added these two dependencies.

@All users:
I might merge this package into llvm-svn is there any reason why you chose this (llvm-toolchain-svn) one over llvm-svn that would prevent this merge?

yan12125 commented on 2015-01-08 08:46

Requires ocaml-ctypes and ocaml-ounit for building

bouhappy commented on 2014-07-02 17:01

I managed to create a correct Patch from the link provided by lordheavy, and compile. However, during installation lib32-llvm-svn conflict with llvm-svn, for the following files:

lib32-llvm-svn: /usr/share/llvm/cmake/AddLLVM.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/AddLLVMDefinitions.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/AddSphinxTarget.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/ChooseMSVCCRT.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/FindSphinx.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/GetSVN.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/HandleLLVMOptions.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/HandleLLVMStdlib.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/LLVM-Config.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/LLVMConfig.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/LLVMConfigVersion.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/LLVMExports.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/LLVMParseArguments.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/LLVMProcessSources.cmake exists in filesystem
lib32-llvm-svn: /usr/share/llvm/cmake/TableGen.cmake exists in filesystem


I am not sure if it's necessary that I give a similar comment on the lib32-llvm-svn package. Afterall, this issue might not apply to this package.

Krejzi commented on 2014-07-02 15:48

lordheavy posted a link to the necessary patch if building with gcc. I don't maintain lib32-llvm-svn so there is nothing I can do about it.

bouhappy commented on 2014-07-02 15:46

Yes, that's also been my first try, but it fails at compile time with:

llvm::cl::parser<llvm::PassInfo const*>::getOption(unsigned int) const'

which is the error posted by shosca. Somehow, you've made a change to use clang on the 19th, and that did it for the compilation. It seem that lib32-llvm-svn is still suffering of the same issue.

I don't mind modifying the PKGBUILD before compiling, I would just like to know what changes you've made, since llvm-svn just compile without errors now, but lib32-llvm-svn still has this error.

Krejzi commented on 2014-07-01 16:45

There is lib32-llvm-svn if that's what you are looking for

bouhappy commented on 2014-07-01 15:15

Is there a way to get a lib32-* equivalent of the packages produced by llvm. I run Wine in 32 bit environment for some application (okay... games) and it's a required.

shosca commented on 2014-06-20 01:11

@lordheavy the patch fixes the build

lordheavy commented on 2014-06-19 23:15

@Krejzi

A fix is proposed on the ML about the breakage:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140616/222509.html

Krejzi commented on 2014-06-19 18:58

I have uploaded new, real split package PKGBUILD that provides clang-svn too. It now requires clang at build time and package will be built using clang until gcc in [extra] is capable of doing the same again.

Krejzi commented on 2014-06-19 15:04

I can now confirm the build error too. Submitted a bug to llvm upstream.

http://llvm.org/bugs/show_bug.cgi?id=20080

Problem is in gcc-4.9.x. I can build it with clang/clang++. Just change "CC=gcc CXX=g++" to "CC=clang CXX=clang++". Make sure you have clang installed before that.

Krejzi commented on 2014-06-19 14:10

I can now confirm the build error too. Submitted a bug to llvm upstream.

http://llvm.org/bugs/show_bug.cgi?id=20080

narnith commented on 2014-06-18 22:26

Getting the same error as shosca.

shosca commented on 2014-06-16 12:23

Yea build fails with rev 211017

http://pastebin.com/xL65Safm

Krejzi commented on 2014-06-13 23:13

Maybe you just got a revision with some regression. Can you reproduce with latest svn?

shosca commented on 2014-06-13 16:02

The build is failing for me with:/tmp/llvm-svn/src/llvm/tools/bugpoint/Release/bugpoint.o: In function `llvm::cl::list<llvm::PassInfo const*, bool, llvm::PassNameParser>::getExtraOptionNames(llvm::SmallVectorImpl<char const*>&)':
bugpoint.cpp:(.text._ZN4llvm2cl4listIPKNS_8PassInfoEbNS_14PassNameParserEE19getExtraOptionNamesERNS_15SmallVectorImplIPKcEE[_ZN4llvm2cl4listIPKNS_8PassInfoEbNS_14PassNameParserEE19getExtraOptionNamesERNS_15SmallVectorImplIPKcEE]+0x76): undefined reference to `llvm::cl::parser<llvm::PassInfo const*>::getOption(unsigned int) const'
collect2: error: ld returned 1 exit status

Full log: http://pastebin.com/GrY4PjNN

Krejzi commented on 2014-04-30 22:11

Not sure. Do you have gcc-4.9.0 installed? If so, try rebuilding the package.

mmstick commented on 2014-04-30 21:41

Any fix for:

libGL error: dlopen /usr/lib/xorg/modules/dri/swrast_dri.so failed (/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/lib/libLLVM-3.5.0svn.so))

zanny commented on 2014-03-16 18:35

==> Starting package_llvm-libs-svn()...
install: cannot stat ‘/mnt/Storage/Code/pkgbuild/llvm-svn/src/libLLVM-3.5svn.so’: No such file or directory
==> ERROR: A failure occurred in package_llvm-libs-svn().
Aborting...
/mnt/Storage/Code/pkgbuild/llvm-svn/src/libLLVM-3.5svn.so: broken symbolic link to `/mnt/Storage/Code/pkgbuild/llvm-svn/pkg/llvm-svn/usr/lib/libLLVM-3.5.0svn.so'

These are the contents of that directory, note no libLLVM-3.5.0svn.so:

BugpointPasses.so libLLVMLTO.a libLLVMSelectionDAG.a
LLVMgold.so libLLVMLineEditor.a libLLVMSparcAsmParser.a
bfd-plugins libLLVMLinker.a libLLVMSparcAsmPrinter.a
libLLVMAArch64AsmParser.a libLLVMMC.a libLLVMSparcCodeGen.a
libLLVMAArch64AsmPrinter.a libLLVMMCDisassembler.a libLLVMSparcDesc.a
libLLVMAArch64CodeGen.a libLLVMMCJIT.a libLLVMSparcDisassembler.a
libLLVMAArch64Desc.a libLLVMMCParser.a libLLVMSparcInfo.a
libLLVMAArch64Disassembler.a libLLVMMSP430AsmPrinter.a libLLVMSupport.a
libLLVMAArch64Info.a libLLVMMSP430CodeGen.a libLLVMSystemZAsmParser.a
libLLVMAArch64Utils.a libLLVMMSP430Desc.a libLLVMSystemZAsmPrinter.a
libLLVMARMAsmParser.a libLLVMMSP430Info.a libLLVMSystemZCodeGen.a
libLLVMARMAsmPrinter.a libLLVMMipsAsmParser.a libLLVMSystemZDesc.a
libLLVMARMCodeGen.a libLLVMMipsAsmPrinter.a libLLVMSystemZDisassembler.a
libLLVMARMDesc.a libLLVMMipsCodeGen.a libLLVMSystemZInfo.a
libLLVMARMDisassembler.a libLLVMMipsDesc.a libLLVMTableGen.a
libLLVMARMInfo.a libLLVMMipsDisassembler.a libLLVMTarget.a
libLLVMAnalysis.a libLLVMMipsInfo.a libLLVMTransformUtils.a
libLLVMAsmParser.a libLLVMNVPTXAsmPrinter.a libLLVMVectorize.a
libLLVMAsmPrinter.a libLLVMNVPTXCodeGen.a libLLVMX86AsmParser.a
libLLVMBitReader.a libLLVMNVPTXDesc.a libLLVMX86AsmPrinter.a
libLLVMBitWriter.a libLLVMNVPTXInfo.a libLLVMX86CodeGen.a
libLLVMCodeGen.a libLLVMObjCARCOpts.a libLLVMX86Desc.a
libLLVMCore.a libLLVMObject.a libLLVMX86Disassembler.a
libLLVMCppBackendCodeGen.a libLLVMOption.a libLLVMX86Info.a
libLLVMCppBackendInfo.a libLLVMPowerPCAsmParser.a libLLVMX86Utils.a
libLLVMDebugInfo.a libLLVMPowerPCAsmPrinter.a libLLVMXCoreAsmPrinter.a
libLLVMExecutionEngine.a libLLVMPowerPCCodeGen.a libLLVMXCoreCodeGen.a
libLLVMHexagonAsmPrinter.a libLLVMPowerPCDesc.a libLLVMXCoreDesc.a
libLLVMHexagonCodeGen.a libLLVMPowerPCDisassembler.a libLLVMXCoreDisassembler.a
libLLVMHexagonDesc.a libLLVMPowerPCInfo.a libLLVMXCoreInfo.a
libLLVMHexagonInfo.a libLLVMR600AsmPrinter.a libLLVMipa.a
libLLVMIRReader.a libLLVMR600CodeGen.a libLLVMipo.a
libLLVMInstCombine.a libLLVMR600Desc.a libLTO.a
libLLVMInstrumentation.a libLLVMR600Info.a libLTO.so
libLLVMInterpreter.a libLLVMRuntimeDyld.a
libLLVMJIT.a libLLVMScalarOpts.a

Instead, it is in llvm-svn/pkg/llvm-libs-svn/usr/lib. So you awnt to fix the pkgbuild to look for it there.

Behem0th commented on 2014-03-05 23:11

behem0th@ArchLinux ~/AUR/X11/llvm-svn :( $ ls -l src/
итого 30784
-rwxr-xr-x 1 behem0th behem0th 31510497 мар 6 03:00 libLLVM-3.5.0svn.so
lrwxrwxrwx 1 behem0th behem0th 72 мар 6 03:00 libLLVM-3.5svn.so -> /home/behem0th/AUR/X11/llvm-svn/pkg/llvm-svn/usr/lib/libLLVM-3.5.0svn.so
drwxr-xr-x 1 behem0th behem0th 712 мар 6 02:17 llvm
lrwxrwxrwx 1 behem0th behem0th 52 мар 6 02:13 llvm-Config-config.h -> /home/behem0th/AUR/X11/llvm-svn/llvm-Config-config.h
lrwxrwxrwx 1 behem0th behem0th 57 мар 6 02:13 llvm-Config-llvm-config.h -> /home/behem0th/AUR/X11/llvm-svn/llvm-Config-llvm-config.h
drwxr-xr-x 1 behem0th behem0th 10556 мар 6 03:00 ocaml
drwxr-xr-x 1 behem0th behem0th 8 мар 6 03:00 ocamldoc

Behem0th commented on 2014-03-05 23:03

==> Tidying install...
-> Purging unwanted files...
-> Compressing man and info pages...
==> Creating package "llvm-svn"...
-> Generating .PKGINFO file...
-> Generating .MTREE file...
-> Compressing package...
==> Starting package_llvm-libs-svn()...
install: cannot stat '/home/behem0th/AUR/X11/llvm-svn/src/libLLVM-3.5svn.so': No such file or directory
==> ERROR: A failure occurred in package_llvm-libs-svn().
Aborting...
What could be the problem?

Krejzi commented on 2014-02-26 03:56

Please use llvm-svn package. It also builds clang-svn, shared and static libraries as well.

cbab commented on 2014-02-26 03:32

Updated PKGBUILD as per @zman0900 gist. Thanks!
I will disown this package since I don't have that much time to properly maintain it anymore. Thanks to everyone and their suggestions.

zman0900 commented on 2014-02-25 06:34

I got impatient so I went ahead and updated the PKGBUILD based on the repo one so it will build the clang packages too.

https://gist.github.com/zman0900/9203522

Krejzi commented on 2014-01-30 18:07

I'd suggest that you simply add clang packaging here and I'll redirect people from clang-svn to this package. If they both were to merge, people won't know where to look for clang-svn since aur doesn't support split packages.

Zucca commented on 2014-01-29 16:33

What's worse - I cannot figure out where to put --enable-shared ;(

Lone_Wolf commented on 2014-01-29 15:20

namcap reports the llvm-svn documentation is installed in a non-standard directory, /usr/docs .

The llvm repo packge uses this in prepare() to fix that :
# Fix docs installation directory
sed -i 's:\$(PROJ_prefix)/docs/llvm:$(PROJ_prefix)/share/doc/llvm:' \
Makefile.config.in

cbab commented on 2014-01-28 16:57

@Krejzi: Yep sure we can merge both packages.

Krejzi commented on 2014-01-14 16:21

Are you still okay with merging clang-svn into this package? I am now maintainer of clang-svn.

schulmar commented on 2013-12-28 17:37

@richard_vock I brushed up the PKGBUILD from llvmlinux-toolchain-svn-git and obviously forgot to remove these dependencies/conflicts (so far I had no problem with it). I removed it from the conflicts and provides part.

richard_vock commented on 2013-12-28 16:02

Why is libc++-svn in both optdepends and conflicts? As far as I can tell libc++ is not included...

minus commented on 2013-12-24 12:57

Any particular reason that shared libs are not built?

frankivo commented on 2013-12-23 09:10

pkgver() {
svn info http://llvm.org/svn/llvm-project|egrep ^Revision|awk {'print $2'}
}

No need for manual checking the revision and updating the PKGBUILD anymore.

cbab commented on 2013-12-10 14:23

@Krejzi: Oops totally missed the headers files. Everything should be fine now. As for the merge of clang-svn in this PKGBUILD, I don't mind if the current maintainer is okay with that.

Let me know if you encounter any other issues.

Krejzi commented on 2013-12-10 13:54

Hello, would you care to merge with llvm-svn package? It would avoid duplication and some of us would need llvm-svn with clang for R600/Radeonsi OpenCL support. Thanks in advance!

Krejzi commented on 2013-12-10 13:50

Sorry for multiple comments, but this still misses what I asked for - two header files available in llvm in [extra] which would allow me to build and use lib32-llvm-svn package correctly.

Krejzi commented on 2013-12-10 13:43

Hm, now we would just need clang and compiler-rt built from the same source so we could utilize R600/Radeonsi OpenCL support in Mesa. Would you care adding clang-svn to the package if the maintainer agrees to merge clang-svn into this package?

Krejzi commented on 2013-12-10 13:41

why are there two options() lines?

cbab commented on 2013-12-10 13:30

Updated with suggestion from @oliv.
@Krejzi let me know if you have any other issue with the package.

oliv commented on 2013-12-09 18:47

Here is the package synchronized with llvm from extra, using multiple package targets (llvm-svn, llvm-libs-svn, llvm-ocaml-svn...):
# Maintainer: Christian Babeux <christian.babeux@0x80.ca>
# Contributor: Thomas Dziedzic < gostrc at gmail >
# Contributor: Roberto Alsina <ralsina@kde.org>
# Contributor: Tomas Lindquist Olsen <tomas@famolsen.dk>
# Contributor: Anders Bergh <anders@archlinuxppc.org>
# Contributor: Tomas Wilhelmsson <tomas.wilhelmsson@gmail.com>

pkgbase=llvm-svn
pkgname=llvm-svn
true && pkgname=('llvm-svn' 'llvm-libs-svn' 'llvm-ocaml-svn')

_pkgname='llvm'
pkgver=196580
pkgrel=1
pkgdesc='Low Level Virtual Machine - Compiler infrastructure.'
arch=('i686' 'x86_64')
url="http://llvm.org"
license=('custom:University of Illinois/NCSA Open Source License')
makedepends=('subversion' 'libffi' 'python2' 'ocaml' 'python-sphinx')
options=('staticlibs')
source=("${_pkgname}::svn+http://llvm.org/svn/llvm-project/llvm/trunk")
sha1sums=('SKIP')
# this is always the latest svn so debug info can be useful
options=('!strip')

pkgver()
{
cd "$SRCDEST/${_pkgname}"
svnversion | tr -d [A-z]
}

build()
{
cd "${srcdir}/${_pkgname}"

# Apply strip option to configure
_optimized_switch="enable"
[[ $(check_option strip) == n ]] && _optimized_switch="disable"

# Include location of libffi headers in CPPFLAGS
CPPFLAGS+=" $(pkg-config --cflags libffi)"

# Force the use of GCC instead of clang
CC=gcc CXX=g++ \
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--enable-shared \
--enable-libffi \
--enable-targets=all \
--disable-expensive-checks \
--disable-debug-runtime \
--disable-assertions \
--with-binutils-include=/usr/include \
--with-python=/usr/bin/python2 \
--$_optimized_switch-optimized

make REQUIRES_RTTI=1
make -C docs -f Makefile.sphinx man
make -C docs -f Makefile.sphinx html
}

package_llvm-svn() {
pkgdesc="Low Level Virtual Machine"
depends=("llvm-libs-svn=$pkgver-$pkgrel" 'perl')
provides=('llvm')
conflicts=('llvm')

cd "${srcdir}/${_pkgname}"

# -j1 is due to race conditions during the installation of the OCaml bindings
make -j1 DESTDIR="$pkgdir" install

# The runtime library goes into llvm-libs
mv "$pkgdir"/usr/lib/libLLVM-*.so "$srcdir"

# OCaml bindings go to a separate package
rm -rf "$srcdir"/{ocaml,ocamldoc}
mv "$pkgdir"/usr/{lib/ocaml,docs/llvm/ocamldoc} "$srcdir"

# Remove duplicate files installed by the OCaml bindings
rm "$pkgdir"/usr/{lib/libllvm*,docs/llvm/ocamldoc.tar.gz}

# Fix permissions of static libs
chmod -x "$pkgdir"/usr/lib/*.a

# Get rid of example Hello transformation
rm "$pkgdir"/usr/lib/*LLVMHello.*

# Symlink LLVMgold.so into /usr/lib/bfd-plugins
# (https://bugs.archlinux.org/task/28479)
install -d "$pkgdir/usr/lib/bfd-plugins"
ln -s ../LLVMgold.so "$pkgdir/usr/lib/bfd-plugins/LLVMgold.so"
ls
#if [[ $CARCH == x86_64 ]]; then
# Needed for multilib (https://bugs.archlinux.org/task/29951)
# Header stubs are taken from Fedora
#for _header in config llvm-config; do
# echo "$pkgdir/usr/include/llvm/Config/$_header"{,-64}.h
# mv "$pkgdir/usr/include/llvm/Config/$_header"{,-64}.h
# cp "$srcdir/llvm-Config-$_header.h" \
# "$pkgdir/usr/include/llvm/Config/$_header.h"
#done
#fi

# Install man pages
install -d "$pkgdir/usr/share/man/man1"
cp docs/_build/man/*.1 "$pkgdir/usr/share/man/man1/"

# Install html docs
cp -r docs/_build/html/* "$pkgdir/usr/docs/$_pkgname/html/"
rm -r "$pkgdir/usr/docs/$_pkgname/html/_sources"

install -Dm644 LICENSE.TXT "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

package_llvm-libs-svn() {
pkgdesc="Low Level Virtual Machine (runtime library)"
depends=('gcc-libs' 'zlib' 'libffi')
provides=('llvm-libs')
conflicts=('llvm-libs')

mkdir -p "$pkgdir"/usr/lib/
install -D "$srcdir"/libLLVM-*.so "$pkgdir/usr/lib/"

install -Dm644 "${srcdir}/${_pkgname}/LICENSE.TXT" \
"$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

package_llvm-ocaml-svn() {
pkgdesc="OCaml bindings for LLVM"
depends=("llvm-svn=$pkgver-$pkgrel" 'ocaml')
provides=('llvm-ocaml')
conflicts=('llvm-ocaml')

cd "${srcdir}/${_pkgname}"

install -d "$pkgdir"/{usr/lib,usr/share/doc/llvm}
cp -r "$srcdir/ocaml" "$pkgdir/usr/lib"
cp -r "$srcdir/ocamldoc" "$pkgdir/usr/share/doc/llvm"

# Remove execute bit from static libraries
chmod -x "$pkgdir"/usr/lib/ocaml/libllvm*.a

install -Dm644 LICENSE.TXT "$pkgdir/usr/share/licenses/llvm-ocaml/LICENSE"
}

# vim:set ts=2 sw=2 et:

oliv commented on 2013-12-09 18:37

Here is the package synchronized with llvm from extra, using multiple package targets (llvm-svn, llvm-libs-svn, llvm-ocaml-svn...):
# Maintainer: Christian Babeux <christian.babeux@0x80.ca>
# Contributor: Thomas Dziedzic < gostrc at gmail >
# Contributor: Roberto Alsina <ralsina@kde.org>
# Contributor: Tomas Lindquist Olsen <tomas@famolsen.dk>
# Contributor: Anders Bergh <anders@archlinuxppc.org>
# Contributor: Tomas Wilhelmsson <tomas.wilhelmsson@gmail.com>

pkgname=('llvm-svn' 'llvm-libs-svn' 'llvm-ocaml-svn')
_pkgname='llvm'
pkgver=196580
pkgrel=1
pkgdesc='Low Level Virtual Machine - Compiler infrastructure.'
arch=('i686' 'x86_64')
url="http://llvm.org"
license=('custom:University of Illinois/NCSA Open Source License')
makedepends=('subversion' 'libffi' 'python2' 'ocaml' 'python-sphinx')
options=('staticlibs')
source=("${_pkgname}::svn+http://llvm.org/svn/llvm-project/llvm/trunk")
sha1sums=('SKIP')
# this is always the latest svn so debug info can be useful
options=('!strip')

pkgver()
{
cd "$SRCDEST/${_pkgname}"
svnversion | tr -d [A-z]
}

build()
{
cd "${srcdir}/${_pkgname}"

# Apply strip option to configure
_optimized_switch="enable"
[[ $(check_option strip) == n ]] && _optimized_switch="disable"

# Include location of libffi headers in CPPFLAGS
CPPFLAGS+=" $(pkg-config --cflags libffi)"

# Force the use of GCC instead of clang
CC=gcc CXX=g++ \
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--enable-shared \
--enable-libffi \
--enable-targets=all \
--disable-expensive-checks \
--disable-debug-runtime \
--disable-assertions \
--with-binutils-include=/usr/include \
--with-python=/usr/bin/python2 \
--$_optimized_switch-optimized

make REQUIRES_RTTI=1
make -C docs -f Makefile.sphinx man
make -C docs -f Makefile.sphinx html
}

package_llvm-svn() {
pkgdesc="Low Level Virtual Machine"
depends=("llvm-libs-svn=$pkgver-$pkgrel" 'perl')
provides=('llvm')
conflicts=('llvm')

cd "${srcdir}/${_pkgname}"

# -j1 is due to race conditions during the installation of the OCaml bindings
make -j1 DESTDIR="$pkgdir" install

# The runtime library goes into llvm-libs
mv "$pkgdir"/usr/lib/libLLVM-*.so "$srcdir"

# OCaml bindings go to a separate package
rm -rf "$srcdir"/{ocaml,ocamldoc}
mv "$pkgdir"/usr/{lib/ocaml,docs/llvm/ocamldoc} "$srcdir"

# Remove duplicate files installed by the OCaml bindings
rm "$pkgdir"/usr/{lib/libllvm*,docs/llvm/ocamldoc.tar.gz}

# Fix permissions of static libs
chmod -x "$pkgdir"/usr/lib/*.a

# Get rid of example Hello transformation
rm "$pkgdir"/usr/lib/*LLVMHello.*

# Symlink LLVMgold.so into /usr/lib/bfd-plugins
# (https://bugs.archlinux.org/task/28479)
install -d "$pkgdir/usr/lib/bfd-plugins"
ln -s ../LLVMgold.so "$pkgdir/usr/lib/bfd-plugins/LLVMgold.so"
ls
#if [[ $CARCH == x86_64 ]]; then
# Needed for multilib (https://bugs.archlinux.org/task/29951)
# Header stubs are taken from Fedora
#for _header in config llvm-config; do
# echo "$pkgdir/usr/include/llvm/Config/$_header"{,-64}.h
# mv "$pkgdir/usr/include/llvm/Config/$_header"{,-64}.h
# cp "$srcdir/llvm-Config-$_header.h" \
# "$pkgdir/usr/include/llvm/Config/$_header.h"
#done
#fi

# Install man pages
install -d "$pkgdir/usr/share/man/man1"
cp docs/_build/man/*.1 "$pkgdir/usr/share/man/man1/"

# Install html docs
cp -r docs/_build/html/* "$pkgdir/usr/docs/$_pkgname/html/"
rm -r "$pkgdir/usr/docs/$_pkgname/html/_sources"

install -Dm644 LICENSE.TXT "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

package_llvm-libs-svn() {
pkgdesc="Low Level Virtual Machine (runtime library)"
depends=('gcc-libs' 'zlib' 'libffi')
provides=('llvm-libs')
conflicts=('llvm-libs')

mkdir -p "$pkgdir"/usr/lib/
install -D "$srcdir"/libLLVM-*.so "$pkgdir/usr/lib/"

install -Dm644 "${srcdir}/${_pkgname}/LICENSE.TXT" \
"$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

package_llvm-ocaml-svn() {
pkgdesc="OCaml bindings for LLVM"
depends=("llvm-svn=$pkgver-$pkgrel" 'ocaml')
provides=('llvm-ocaml')
conflicts=('llvm-ocaml')

cd "${srcdir}/${_pkgname}"

install -d "$pkgdir"/{usr/lib,usr/share/doc/llvm}
cp -r "$srcdir/ocaml" "$pkgdir/usr/lib"
cp -r "$srcdir/ocamldoc" "$pkgdir/usr/share/doc/llvm"

# Remove execute bit from static libraries
chmod -x "$pkgdir"/usr/lib/ocaml/libllvm*.a

install -Dm644 LICENSE.TXT "$pkgdir/usr/share/licenses/llvm-ocaml/LICENSE"
}

# vim:set ts=2 sw=2 et:

Krejzi commented on 2013-12-08 17:42

Please sync with llvm from [extra] and, if possible, add necessarry files required to have lib32-llvm-svn, which are also available in [extra].

justinzane commented on 2013-11-27 06:03

This is the tools/gold/README:
This directory contains a plugin that is designed to work with binutils
gold linker. At present time, this is not the default linker in
binutils, and the default build of gold does not support plugins.

Obtaining binutils:

cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src login
{enter "anoncvs" as the password}
cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils

This will create a src/ directory. Make a build/ directory and from
there configure binutils with "../src/configure --enable-gold --enable-plugins".
Then build binutils with "make all-gold".

To build the LLVMgold plugin, configure LLVM with the option
--with-binutils-include=/path/to/binutils/src/include/ --enable-pic. To use the
plugin, run "ld-new --plugin /path/to/LLVMgold.so".
Without PIC libLTO and LLVMgold are not being built (because they would fail
link on x86-64 with a relocation error: PIC and non-PIC can't be combined).
As an alternative to passing --enable-pic, you can use 'make ENABLE_PIC=1' in
your entire LLVM build.

How on earth to I edit the PKGBUILD for this?

justinzane commented on 2013-11-27 06:00

LLVMgold.so, the linker plugin seems to have disappeared after replacing the repo clang with this; which breaks a number of my builds. How to recover it?

schulmar commented on 2013-11-11 16:41

It seems this version is too old. You could try to build with gcc instead of clang. The new package version does not depend on clang to build lldb anymore. It takes a bit longer but should be possible (I tried it with the repository version yesterday). Another thing you could try would be to remove the lldb part from the PKGBUILD, build and install LLVM+clang and then try the full install which should then benefit from the newly installed clang version.

aksr commented on 2013-11-11 16:22

Version from the official repo: clang version 3.3 (tags/RELEASE_33/final)

schulmar commented on 2013-11-11 16:07

Which version of clang are you using for compilation?

aksr commented on 2013-11-11 16:04

schulmar: I'm unable to compile it. Here's a output snippet: https://privatepaste.com/29de3eb45d
I'm using clang from the official repository(extra).

schulmar commented on 2013-11-10 18:03

It seems configure and make picked up the wrong python version (at least at my place). I worked around that and for me it builds now.

schulmar commented on 2013-11-10 14:24

@aksr: Please provide further information how the build failed.

aksr commented on 2013-11-09 21:23

Unable to compile lldb:
I used: CXX=clang++ makepkg

hpohl commented on 2013-10-31 19:17

Thank you, just noticed the libs were missing.

H3g3m0n commented on 2013-10-31 03:26

I think this needs:
options=('staticlibs')

Things like the address sanitizer depend on .a files that are getting stripped.

The non-aur clang package also has that option. But beware it is a 1.1GiB install size with staticlibs.

ytj commented on 2013-10-11 10:27

Consider following the https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines and change the PKGBUILD please.

cbab commented on 2013-09-26 19:58

@jackd: Probably only changing CFLAGS="-m32" and perhaps using the lib32 versions of the makedepends dependencies.

jackd commented on 2013-09-25 06:27

What would it take to build a 32-bit version of this package on a 64-bit system?

hpohl commented on 2013-08-13 11:42

You can add -DBUILD_SHARED_LIBS=ON to the cmake commands in the PKGBUILD.

Behem0th commented on 2013-08-13 03:35

When I try to build mesa from git with --enable-opencl i have it warning:

configure: error: Could not find llvm shared libraries:
Please make sure you have built llvm with the --enable-shared option
and that your llvm libraries are installed in /usr/lib
If you have installed your llvm libraries to a different directory you
can use the --with-llvm-prefix= configure flag to specify this directory.
NOTE: Mesa is attempting to use llvm shared libraries because you have
passed one of the following options to configure:
--with-llvm-shared-libs
--enable-opencl
If you do not want to build with llvm shared libraries and instead want to
use llvm static libraries then remove these options from your configure
invocation and reconfigure.

In llvm-svn package used configure and there simply add option --enable-shared.
But in your package used cmake.
How can I add an option --enable-shared in this package?

cbab commented on 2013-06-07 03:06

s/CVS/VCS/ :)

jellysheep commented on 2013-06-06 19:14

@cbab: thank you very much for your fast reply, it works just great! :)

cbab commented on 2013-06-06 15:38

s/CVS/VCS/ :)

cbab commented on 2013-06-06 15:36

Updated PKGBUILD with latest CVS guidelines. Let me know if you have any other issues. Thanks for reporting.

jellysheep commented on 2013-06-06 13:57

@cbab: Could you please update the PKGBUILD script according to the link mmm posted or as explained in the Archlinux wiki pages?
http://allanmcrae.com/2012/08/changes-to-vcs-packaging-support-in-makepkg/
llvm revisions change minutely and if you build this llvm-svn package as it is, you will just get revision 177654 as mentioned in the PKGBUILD, instead of rev 183410.
If you need help updating the build script, just tell and I'll have it a try.

Svenstaro commented on 2013-04-20 18:15

Go ahead and update it. I disowned it.

Anonymous comment on 2013-04-20 17:21

Desperately needs an svn revision update. There's a horrible crash on a pure virtual function call on any attempt at using C++11's std::thread.

( http://llvm.org/bugs/show_bug.cgi?id=12730 )

cbab commented on 2013-04-12 16:32

Alright, I was not sure how to approach this. I will take a look and post an updated PKGBUILD. Thanks!

mmm commented on 2013-04-12 16:30

Btw, you might have a look at the new makepkg's goodness for svn packages: http://allanmcrae.com/2012/08/changes-to-vcs-packaging-support-in-makepkg/

mmm commented on 2013-04-02 12:49

would it be possible to somewhat reduce the svn-checkout and resulting build size?
llvm-svn has 1.3GB instead of 82MB for llvm..

cbab commented on 2013-03-21 20:45

Updated with suggestions from lordheavy.
I had some issues with the license length limitation (40 chars) in the upload script on the AUR. The license is custom:University of Illinois/NCSA Open Source License.

remyoudompheng commented on 2013-03-09 12:54

Disowning for people wanting to give love.

lordheavy commented on 2013-03-09 12:32

it should be PYTHON=/usr/bin/python2 instead of PYTHON=python2

Svenstaro commented on 2012-11-04 04:54

You're right. Updated.

aatch commented on 2012-11-03 04:34

PKGBUILD file needs change from `gcc=$_gcc_ver` to `gcc>=$_gcc_ver`,
or change of $_gcc_ver to be less specific (I.E 4.7 rather than 4.7.0), since current
GCC version from the main repo is 4.7.2, it builds fine, but the PKGBUILD doesn't
work as-is.

aatch commented on 2012-11-03 04:33

PKGBUILD file needs change from `gcc=$_gcc_ver` to `gcc>=$_gcc_ver`,
or change of $_gcc_ver to be less specific (I.E 4.7 rather than 4.7.0)

randomize46 commented on 2012-10-13 22:57

Seems like problem fixed in upstream, everything builds now.

randomize46 commented on 2012-10-11 20:13

Here is log, not very informative, but maybe helps
http://pastebin.com/raw.php?i=rQsTPvGg

I also searched for *.log files in building directory and found this
./aur-clang-svn/src/llvm-build/build/CMakeFiles/CMakeError.log
http://pastebin.com/raw.php?i=igGZaTdK

I have no idea where else cmake could hide details on this error, but will try to provide any helpful info

Svenstaro commented on 2012-10-11 14:15

Also report the problem upstream.

Svenstaro commented on 2012-10-11 14:15

Please pastebin the error.

randomize46 commented on 2012-10-10 20:40

Can't build after latest gcc update, standard trick with chaging _gcc_ver=4.7.2 in PKGBUILD doesn't help, build fails on 18% with message:

make[2]: Leaving directory `/tmp/yaourt-tmp-randy/aur-clang-svn/src/llvm-build/build'
/usr/bin/cmake -E cmake_progress_report /tmp/yaourt-tmp-randy/aur-clang-svn/src/llvm-build/build/CMakeFiles 38 39 40
[ 18%] Built target LLVMSupport
make[1]: Leaving directory `/tmp/yaourt-tmp-randy/aur-clang-svn/src/llvm-build/build'
make: *** [all] Error 2

System:
Linux randy-station 3.5.6-1-ARCH #1 SMP PREEMPT Sun Oct 7 19:30:49 CEST 2012 x86_64 GNU/Linux
gcc-multilib 4.7.2-1

Anonymous comment on 2012-06-20 18:48

The current gcc version has been updated to 4.7.1, preventing this package to build as it explictily requires gcc=4.7.0.
Changing the "gcc=_gcc_ver" to "gcc>=_gcc_ver" fixes the build.

mosra commented on 2012-04-27 14:07

I had the same problems with includes as reuben.bond, with his modifications everything works.

I modified the PKGBUILD for easier rebuilding without the need to compile everything again every time, in case someone is interested, here's the patch: https://github.com/mosra/archlinux/commit/76d6c4b99a2e22889c016c026a3c807f2c21a958

ducakar commented on 2012-04-25 00:10

http://llvm.org/bugs/show_bug.cgi?id=11926
http://llvm.org/bugs/show_bug.cgi?id=12644
https://bugzilla.redhat.com/show_bug.cgi?id=791365

It's not yet clear whether the bug is in GCC or LLVM/Clang. LLVM guys think it's a GCC bug (they are closing all bug reports), while the lead GCC developer thinks it might be a strict aliasing bug in LLVM/Clang. I'm afraid it won't be resolved soon, so just include the workaround ;)

Svenstaro commented on 2012-04-23 01:20

Isn't this just a workaround? Since this is the svn package, we can easily fix it by showing upstream the wrong behavior. Did you open an upstream bug? If so, please link it here.

ducakar commented on 2012-04-23 01:03

Please add "-fno-tree-pre" to CFLAGS/CXXFLAGS because clang crashes when run with "-Wall".

See https://bugs.archlinux.org/task/29481 for more info.

remyoudompheng commented on 2012-04-07 17:13

Reuploaded with some fixes from official PKGBUILD.
More are probably needed.

Svenstaro commented on 2012-04-03 16:08

Fixed and updated to gcc 4.7.0.

randomize46 commented on 2012-04-03 06:26

Please, update PKGBUILD _gcc_ver=4.6.2 to _gcc_ver=4.6.3, because it tries to build a gcc before building clang actually

Svenstaro commented on 2012-02-18 02:49

I just built on another system and do not run into any issues either. Package here: http://178.63.102.135/svens_stuff/clang-svn-150860-1-x86_64.pkg.tar.xz

reuben.bond commented on 2012-02-17 20:52

If anyone else is able to reproduce, please chime in. I certainly cannot produce Svenstaro's results without patching the PKGBUILD.

I have had an email asking me for the PKGBUILD, saying that the pastebin had expired (it seems alright again now), which suggests I'm not alone.

Svenstaro commented on 2012-02-16 06:57

The current package works without any trouble of finding the STL headers for me. Cannot reproduce.

reuben.bond commented on 2012-02-12 07:27

For me, it was failing to find iostream. Eg, the following would fail:
#include <iostream>

int main()
{
std::cout << "Hello, world!\n";
}

$ clang++ test.cpp
test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 diagnostic generated.

Svenstaro commented on 2012-02-11 17:54

Can you give me a minimal example that fails? A Hello world works for me.

reuben.bond commented on 2012-02-04 09:25

On my system, include paths were not working, so I have updated the PKGBUILD in this paste: http://pastebin.ca/2109612
It uses the gcc executable to get the C++ include search paths, and passes them into cmake via -DC_INCLUDE_DIRS.
I hope others find this useful!

Note: A Clang change made in November 2011 stopped the older method of patching the InitHeaderSearch.cpp file from working on Linux and Windows systems, moving the responsibility to the Driver.

Svenstaro commented on 2011-11-07 19:29

Fixed.

EdwardXXIV commented on 2011-11-07 10:54

I had to add

-DPYTHON_EXECUTABLE=/usr/bin/python2 \

to the cmake line to make it compile.

Svenstaro commented on 2011-10-18 00:25

Quite right. Old package here: http://ompldr.org/vYXV3bQ

jonnor commented on 2011-10-17 23:53

The package is quite hard to read/review quickly with all the things that are commented out. No-one has complained about issues for several months, perhaps it can all be removed? You could toss the old PKGBUILD up somewhere on the net as a backup if you think some of it might become useful again.

jonnor commented on 2011-10-17 23:17

Why flagged out of date?

Svenstaro commented on 2011-07-29 18:22

Package updated and simplified a lot. Please report any errors you run into. For now I'm leaving the old package commented in this one as well as all the patches of which none is actually used right now.

WFCody commented on 2011-05-03 15:29

@heftig

Another alternative is the self-hosting lll-git package (sorry for blowing my own horn)
https://aur.archlinux.org/packages.php?ID=45733
I am currently considering the possibility of including compiler-rt in the build to completely avoid libgcc dependency.
Feedback on the package is welcome :)

heftig commented on 2011-04-12 22:55

This is on hiatus for a while until I get it to build again.

In the meantime, I recommend clang from [community-testing]: It provides the same patches and isn't broken by gcc 4.6.

jedbrown commented on 2011-02-23 18:55

Please also change the symlink to what is shown below (it is no longer llvm/libLLVMgold.so).

# Symlink the gold plugin where clang expects it
ln -s "llvm/LLVMgold.so" "$pkgdir/usr/lib/LLVMgold.so"

jedbrown commented on 2011-02-23 18:28

The path "Release/bin/clang" is hard-coded, but you have logic to create a debug build when the strip option is disabled (which puts everything in a different build directory).

jedbrown commented on 2011-02-23 11:45

Patches need an update (rev 126309).

-> Patching...
patching file lib/Frontend/InitHeaderSearch.cpp
Hunk #1 succeeded at 732 (offset 18 lines).
patching file lib/Driver/ToolChains.cpp
Hunk #1 FAILED at 1344.
1 out of 1 hunk FAILED -- saving rejects to file lib/Driver/ToolChains.cpp.rej
Aborting...

Anonymous comment on 2011-02-16 15:06

OMG these C++ error messages are so sweet :D

Anonymous comment on 2011-02-16 15:00

I installed gcc44 from aur (but bumped it from 4.4.4 to 4.4.5) and made these changes to clang
http://pastebin.com/kyVpC7sM
Works like a charm, except that I get linker problems when linking to a boost lib that was compiled with gcc-4.5 -____-

@big_gie thanks, I added myself to the CC list of this bug. This is certainly a good workaround, but I feel more comfortable to have clang look at the right place to begin with.

big_gie commented on 2011-02-16 13:19

Here are the CFLAGS I need to add when compiling something with clang with gcc 4.5 installed:
-I/opt/gcc34/include/c++/3.4.6 -I/opt/gcc34/include/c++/3.4.6/x86_64-unknown-linux-gnu -nostdinc++

big_gie commented on 2011-02-16 12:53

@MaikB:
Yes, it's a known issue. See http://llvm.org/bugs/show_bug.cgi?id=7069

Anonymous comment on 2011-02-16 11:33

Note: At the moment clang isn't able to handle all bits gcc-4.5s c++ standard library. It uses some c++0x features that clang doesn't support yet, see http://comments.gmane.org/gmane.comp.compilers.clang.devel/10747 .

I'm building gcc44 from aur now to see what has to be done to make it work.

jedbrown commented on 2011-02-09 16:04

/usr/lib/llvm/libLLVMgold.so is not being installed so linking with clang fails:

$ clang -v foo.c
clang version 2.9 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name foo.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.0.20101217 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 150 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-zmvsG2.o -x c foo.c
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/bin/../lib/clang/2.9/include
/usr/include
End of search list.
"/usr/bin/ld.gold" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbegin.o -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. /tmp/cc-zmvsG2.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crtn.o -plugin /usr/bin/../lib/LLVMgold.so
/usr/bin/ld.gold: error: /usr/bin/../lib/LLVMgold.so: could not load plugin library: /usr/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

heftig commented on 2010-12-19 22:41

Updated again, still requires [testing].

The gold plugin is unconditionally enabled now, so for LTO, -flto or -O4 is enough.

Building 32-bit via -m32 works, too (needs gcc-multilib, however).

heftig commented on 2010-12-19 19:32

Requires [testing] for now, but LTO should work:

clang -flto -use-gold-plugin foo.c

EdwardXXIV commented on 2010-12-03 21:59

Updated cppheaders.patch: http://aur.pastebin.com/xkPGiibJ

Thanks for maintaining this package!

WFCody commented on 2010-11-22 21:32

Would you be interested in uploading a Clang-svn-selfhost package as well where the dependencies are changed from GCC to Clang? Otherwise I will do that. I do not want to step on anyones toes since I am new here and since this as far as I can see would be a very minor modification of this package.

jedbrown commented on 2010-11-08 19:06

Probably an upstream issue, but

$ clang -v foo.c
clang version 2.9 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name foo.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1.20100521 -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 150 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-oRqdUQ.o -x c foo.c
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/bin/../lib/clang/2.9/include
/usr/include
End of search list.
"/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out crt1.o crti.o crtbegin.o -L -L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../.. /tmp/cc-oRqdUQ.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o
/usr/bin/ld: crt1.o: No such file: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

EdwardXXIV commented on 2010-08-13 17:39

the cppheaders.patch needs to be updated again. thanks for maintaining this package!

big_gie commented on 2010-06-28 17:08

I can't build this anymore:
-It seems to depend on pod2html and pod2man, which perl provides. But these tools are in /usr/lib/perl5/core_perl/bin/ which is not in the PATH.
-The chmod at line 117 fails:
chmod: cannot access `clang-svn/pkg/usr/lib/llvm/*.a': No such file or directory
Static library are in "clang-svn/pkg/usr/lib/llvm/llvm/llvm/llvm/" which looks weird.

I'm rebuilding complety to see if it changes something...

maleadt commented on 2010-05-25 08:13

Hm, it sorted itself out after a remove and manual rebuild :)

maleadt commented on 2010-05-09 09:53

Building of clang-svn has been failing recently:
llvm[5]: Building Clang statement node tables with tblgen
tblgen: Unknown command line argument '-gen-clang-stmt-nodes'. Try: '/var/abs/local/yaourtbuild/clang-svn/src/llvm-build/Release-Asserts/bin/tblgen -help'

big_gie commented on 2010-05-06 14:21

I'm hit with a bug: http://llvm.org/bugs/show_bug.cgi?id=7069
Can anyone else can reproduce it? Is it only on Arch? Anton Korobeynikov said in comment http://llvm.org/bugs/show_bug.cgi?id=7069#c3 that the compilation was fine for him...

Also, "pkgconfig" is missing from makedepends. Or should it go in depends?

heftig commented on 2010-04-25 16:06

Thanks, updated.

EdwardXXIV commented on 2010-04-25 15:02

here's a new cppheader.patch: http://aur.pastebin.com/xfQwHdUx

EdwardXXIV commented on 2010-04-25 15:00

here's a new cppheaders.patch for the new gcc:

Index: lib/Frontend/InitHeaderSearch.cpp
===================================================================
--- lib/Frontend/InitHeaderSearch.cpp (revision 95676)
+++ lib/Frontend/InitHeaderSearch.cpp (working copy)
@@ -533,10 +533,10 @@
"i586-suse-linux", "", "", triple);
AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.4",
"x86_64-suse-linux", "", "", triple);
- // Arch Linux 2008-06-24
- AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.3.1",
+ // Arch Linux 2010-04-25
+ AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.5.0",
"i686-pc-linux-gnu", "", "", triple);
- AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.3.1",
+ AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.5.0",
"x86_64-unknown-linux-gnu", "", "", triple);
// Gentoo x86 2009.1 stable
AddGnuCPlusPlusIncludePaths(