Package Base Details: lib32-llvm-git

Git Clone URL: (read-only, click to copy)
Keywords: clang git llvm
Submitter: yurikoles
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 11
Popularity: 0.004226
First Submitted: 2019-01-11 15:50
Last Updated: 2020-03-20 00:24

Latest Comments

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

kerberizer commented on 2015-09-06 19:27

[HEADS UP] Dependency change

As discussed earlier, lib32-llvm-svn has been changed to depend on llvm-svn, instead of on llvm. For most of you, who have llvm-svn installed anyway, this is NOT going to change anything. For those few, however, who may be using lib32-llvm-svn alongside llvm from the official extra repo, have in mind that you'll have to switch to llvm-svn too, which is probably a good idea anyway.

kerberizer commented on 2015-09-06 13:11

[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 update them 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:

kerberizer commented on 2015-09-06 11:18

[WARNING] The shared library seems broken at the moment, with many symbols not being exported. For more information, please see the comments for the llvm-svn package. A fix is on its way.

kerberizer commented on 2015-08-22 19:22

@Lone_Wolf, thanks! Those are good points and I, too, am increasingly leaning towards keeping the things consistent. However, I'll be travelling tomorrow early morning and will be away for a few days, so it's probably best not to touch the build system right now, as it will need some readjustment. I'll look into this when I'm back home. And, in the meantime, someone else might chime in as well.

@oxalin, I see. If anything interesting comes out from your case upstream, don't forget to post it here. Might come in handy anyway. :)

oxalin commented on 2015-08-22 16:59

@kerberizer, no it's not that bug.

I wished there would be a way to detect automatically the number of cores available though instead of manually setting it. Anyway, I agree with you that we can change/set the value in makepkg.conf.

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