Package Details: clang-svn 8.0.0svn_r340523-1

Git Clone URL: (read-only)
Package Base: llvm-svn
Description: C language family frontend for LLVM
Upstream URL:
Keywords: clang lld lldb llvm
Licenses: custom:University of Illinois
Groups: llvm-toolchain-svn
Conflicts: clang
Provides: clang
Submitter: None
Maintainer: kerberizer (Lone_Wolf)
Last Packager: kerberizer
Votes: 106
Popularity: 1.488453
First Submitted: 2007-08-02 07:15
Last Updated: 2018-08-23 13:04

Dependencies (16)

Required by (344)

Sources (8)

Pinned Comments

kerberizer commented on 2016-08-11 00:39


Please check the following page for information on: - possible problems with this package; - recommendations on how to build it; - availability of binary packages.

You may also use it for bug reports and pull requests.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

gloriouseggroll commented on 2018-10-12 22:36

went to compile this on a fresh arch install, was getting a recommonmark error, installing python-recommonmark fixed it, apparently either python2-recommonmark wasn't enough or arch was using python3 to build as python3 is the default version now for the python package. probably also needed on lib32-llvm-svn

kerberizer commented on 2018-09-09 16:04

@Lone_Wolf, thank you, I've added you as a co-maintainer. I've also transferred the GitHub repos to a separate organization for more flexibility. :)

Lone_Wolf commented on 2018-09-09 15:11

I'm ok with becoming co-maintainer, but do think you should stay as maintainer.

You've always treated llvm as a compiler suite while I only see it as "necessary evil* requirement" for mesa. If I maintained this i'd probably ditch everything not needed for mesa.

Also llvm bug tracking system is almost a black box to me, while you have shown you know how to use it or find out if issues are already in it.

I dislike the license llvm had and the one they're switching to. I also dislike several of their development choices (cmake, svn, no clear method to have multiple installs coexist)

kerberizer commented on 2018-09-09 11:21

@Lone_Wolf, thank you very much for taking care of this. Would you feel fine with taking over the maintainership of the package? You are doing great work with mesa-git already.

Lone_Wolf commented on 2018-09-09 09:26

I have forked kerberizer github repo and am working on adjusting the PKGBUILD.

So far build output is reduced (svn export is rather chatty) , I added a makdepend that's neded for polly and buildtime does appear to be shortened.


NOTE : I am still working on adjusting the PKGBUILD, haven't done runtime tests yet.

Lone_Wolf commented on 2018-09-04 11:00

@zegentz : the time is similar to what i get, haven't checked memory usage. The stripping issue and large size suggest something is wrong on your system. Are you building in /tmp ? What filesystem is your build folder on ?

@kerberizer : The slow building is partially due to the svn export commands used. Iirc those were needed because llvm build needs everything to be in a specific place in the source tree. autotools/make and cmake/make failed unless the files were physically in correct place.

I checked extra/llvm and co, and they switched to cmake/ninja builds. Mesa is now build mesa with meson/ninja and I do have the impression a big part of the speedup comes from using ninja. Also stock llvm now uses only python3 apps during build.

This gives some options to improve/speedup/simplify build :

  • switch to python3

  • build with cmake/ninja

  • verify if cmake/ninja can use the code in the location makepkg puts them. if not , maybe we can change those location or use symlinks.

kerberizer commented on 2018-08-23 13:20

[NOTICE] Polly, the high-level loop and data-locality optimizer and optimization infrastructure for LLVM ( has been added to the build and the binary repo. Apologies for it taking so unnecessarily long (pull request #15 on Github was from July 2017).

kerberizer commented on 2018-08-23 13:18

@zegentz, the automatic builds are indeed quite slow, even on a system with 256 GB of RAM and everything on a ramdisk. Not sure about stripping, but cloning the repositories sometimes takes a good half an hour to an hour. It is quite a heavy build, which was the reason I set up that binary repo at the time. As I don't do manual builds any more (indeed, I don't even use llvm-svn myself for quite a long time already), I'm afraid I can't offer much advice. Hopefully someone else might have a better idea.

zegentz commented on 2018-08-23 11:21

Hi folks,

So for the last four days I've been trying to build this package. At first it was built without a chroot, but I eventually "learned the error of my ways", so to say, and tried to build it in a chroot, in a similar fashion to the method described on github. In both cases, with or without it being built in a chroot, I experienced the following.

The linkers, combined, kept using 24gb+ of ram (6-8gb each), on a pc which only has 12gbs of ram (just imagine the amount of swapping). I realize that I could've lowered the thread count (from 4 to 1) to solve this part of the problem, but I didn't think of it at the time. Anyways, the builds completed after ~4-4.5hrs, so this doesn't really matter.

So after ~4hrs of building it completed, but it was 33gb large (ouch), just a couple gigabytes too large to cram into my root partition. I tried repackaging it (makepkg -siRe --noprepare) with strip enabled, but it was taking 4+ hours just to strip, and I estimated that it would've taken another 16 hours to complete (based on the # of packages stripped, and the sized of their respective unstriped equivalents).

I later wiped either the chroot folder, or the src folder, depending on whether I was using a chroot or not. I then tried to build llvm-svn again (this time with strip enabled from the start), and... it's been stuck stripping for the last 6-8hrs (for the chrooted version, the non-chrooted version I canceled 4hrs into stripping)!

I do hope this is an unusual occurrence and that I just fucked up somewhere. 33gb of debug symbols strikes me as excessive. (I think it was mostly debug symbols because some of the stripped packages where in the hundred megabytes range, while their non-stripped counterparts were in the 5-10gb range.) And 8hrs of striping sounds excessive-er.

Has anyone experience anything similar? Do your builds, @kerberizer, normally take 8hrs+ to strip? Are non-stripped build usually in the tens of gigabytes range? Got any clues into how I could get it to work out or why this is happening?

Anyways, I've just installed llvm-svn and others from, I guess that's good enough for now, as I only need llvm-svn for mesa-git. But I was hoping that someone might have any advice relating to this, in case I stumble into a similar problem in the near or distant future.

Thanks, -- Hal Gentz

EDIT: rephrased a couple bits.

lahwaacz commented on 2018-08-16 12:27

@Enverex: As a workaround, you don't have to remove the whole llvm-libs-svn package, just deleting the file /usr/lib/bfd-plugins/ is enough...