Package Base Details: lib32-llvm-git

Git Clone URL: (read-only)
Keywords: clang git llvm
Submitter: yurikoles
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 11
Popularity: 0.058031
First Submitted: 2019-01-11 15:50
Last Updated: 2019-11-14 12:52

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

Lone_Wolf commented on 2015-08-19 07:59


arch users should make those changes in /etc/makepkg.conf , not in individual pacakge builds.
Or doesn't llvm-svn make honor locally set makeflags ?

relevant snippet from my /etc/makepkg.conf :
#-- Make Flags: change this for DistCC/SMP systems

oxalin commented on 2015-08-19 03:12

@kerberizer: moving from autotools to cmake was indeed not that hard once you found the options. I was struggling with some targets though: some are failing if you don't tweak your options correctly (like you said in some of your commit's descriptions). I'm still working on an issue reported to the LLVM dev team on the matter.

By the way, great job. I'd like to suggest a small modification to speed up the build process on multicore system:
build() {
+ _cpucount=$(grep -c processor /proc/cpuinfo 2>/dev/null)
+ _jc=$((${_cpucount:-1}))


- make
+ make -j $_jc

You could also add the "-j $_jc" to "make -j $_jc ocaml_doc"

Eriner commented on 2015-08-11 06:45

Thanks for your hard work @kerberizer

kerberizer commented on 2015-08-06 20:40

[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.

kerberizer commented on 2015-08-05 19:43

Fixing this package actually turned out to be not that difficult now that most work had been done in llvm-svn. It's also on GitHub...

Again, all comments and suggestions will be much appreciated.

kerberizer commented on 2015-08-05 14:39

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 llvm-svn package, though I won't be able to fix this one immediately.

Madotsuki commented on 2015-07-31 23:05

==> Starting build()...
configure: error: In-source builds are not allowed. Please configure from a separate build directory!

Krejzi commented on 2015-07-26 16:43

Hmm, I thought I packaged the lib32-mesa-opencl-git but apparently never got to it.

I saw a change in the official lib32-llvm package [1] which lead me to add lib32-clang-svn here too.

If I don't succeed again, I'll just go and drop the clang part. It will however be few more days before I can get to it.


Lone_Wolf commented on 2015-07-26 16:20

If you mean lib32-ocl-icd , that doesn't have a dependency on clang or llvm anymore.

lib32-mesa & lib32-mesa-libgl do depend on llvm, but not on clang.
Also the webpage for mutilib/lib32-clang doesn't list anything as requiring it.

Krejzi commented on 2015-07-25 22:12

It is a requirement to build 32 bit OpenCL ICD library for Radeon as done in the official package. Otherwise, no. Although, it might be questionable why the ocl library might be useful in multilib (my only guess is wine and I have no idea what might use it).