Package Base Details: lib32-llvm-git

Git Clone URL: (read-only, click to copy)
Keywords: clang git llvm
Submitter: yurikoles
Maintainer: Lone_Wolf (rjahanbakhshi)
Last Packager: rjahanbakhshi
Votes: 12
Popularity: 0.019078
First Submitted: 2019-01-11 15:50
Last Updated: 2021-01-27 18:01

Latest Comments

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

Lone_Wolf commented on 2015-08-22 13:43

For programs that have a 64-bit and a 32-bit version, the multilib version is often the 32-bit version just compiled on a different architecture.
In these cases, the multilib version is standalone.

Other programs use parts from their 64-bit "parent" in their multilib version.

I'm certain (building lib32-mesa-git against stock mesa was one of my biggest blunders) Mesa is in the 2nd category , that's why lib32-mesa-git depends on mesa-git .

I'm not sure about llvm, but official lib32-llvm does depend on 64-bit llvm.

kerberizer commented on 2015-08-22 12:58

> lib32-llvm-svn depends on llvm and this should be llvm-svn instead

Yes, I know this, and was thinking about it a while ago. It's quite likely better/safer to set a dependency on llvm-svn, but I thought there might be people who actually do want to have the stable LLVM on native 64-bit and just use the SVN version for multilib. At the same time, llvm-svn provides 'llvm' dependency, so there shouldn't be unnecessary pulls when llvm-svn is already installed. The only case of confusion that I see is if someone decides to install lib32-llvm-svn without having any LLVM installed previously, and then decides to install llvm-svn, which would then conflict with the already pulled in llvm from extra; I guess such cases would be rather unlikely though.

As a matter of fact, I'm not even sure if that dependency is really necessary: it was there when I took over the package and I didn't quite have the time to properly test it. Namcap states it's superfluous and that's exactly what I would expect myself. So, perhaps I might as well remove it completely. Any thoughts?

Lone_Wolf commented on 2015-08-22 12:33

lib32-llvm-svn depends on llvm and this should be llvm-svn instead.

kerberizer commented on 2015-08-19 09:01

Thank you for the kind words, guys. I really appreciate your comments and suggestions.

Lone_Wolf is right about makepkg setting the number of parallel threads according to the setting in makepkg.conf. In fact, the automatic build system that I've set up for the binary repo uses a value as high as `MAKEFLAGS="-j33"', since it has 32 cores. For those who prefer to build the packages themselves, and do this frequently, I'd also strongly recommend using ccache -- but then again, most possibly you already do, since it's quite the obvious thing.

Speaking of the binary repo, I probably should've announced that the builds now are indeed 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 also use GitHub if you have specific issues...

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

@oxalin, is this the bug you were referring to?...

Lone_Wolf commented on 2015-08-19 08:02


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

Default value for archlinux is 2 , useful for single core processors.

-j1 is only needed for progams that fail building with j2 or higher, and those are rare nowadays.

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

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.