Package Base Details: llvm-git

Git Clone URL: https://aur.archlinux.org/llvm-git.git (read-only, click to copy)
Keywords: clang git lld lldb llvm polly
Submitter: yurikoles
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 111
Popularity: 0.088603
First Submitted: 2018-12-05 13:56
Last Updated: 2020-06-08 18:03

Pinned Comments

Lone_Wolf commented on 2019-04-12 20:41

I've looked good at clang-trunk , llvm-svn, repo llvm/clang packages and think this package is now on route to become a worthy successor to llvm-svn .

  • llvm-libs-git holds the runtime libraries.

    It conflicts with the repo llvm-libs package. This is the only way to make sure the llvm linker from git is used, and that's needed for a full dev environment.

  • llvm-git

    has llvm , clang, compiler-rt, ocaml & python bindings, polly , lld , lldb .


The Package now uses a new environment variable to make ninja behave, NINJAFLAGS. If you want to use it adjust the snippet below to your desired values and add it to makepkg.conf.

Incase you are satisfied with ninja defaults you don't need to do anything.

# Add to makepkg.conf
# limit ninja to 20 jobs
# requires special code in PKGBUILD
# see ninja --help for additonal options
NINJAFLAGS="-j20"

The check() function fails rather often, but I do suggest to build with them. If build fails due to test failure you can add --nocheck to skip the tests.

Latest Comments

« First ‹ Previous ... 10 11 12 13 14 15 16 17 18 19 20 ... Next › Last »

kerberizer commented on 2018-08-23 13:20

[NOTICE] Polly, the high-level loop and data-locality optimizer and optimization infrastructure for LLVM (https://polly.llvm.org/) 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.

goddessfreya 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 uni-plovdiv.net, 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/LLVMgold.so is enough...

Enverex commented on 2018-08-16 11:00

Just a heads up, this currently builds LLVM 8.0.0; For some reason, the llvm-libs package that it generates and installs causes lots of other compilations to fail (builds that don't even use LLVM/Clang at all). This issue manifests itself in the error:

"LLVM ERROR: inconsistency in registered CommandLine options"

If you see this error, this package is the cause. Removing llvm-libs will allow you to compile the failing package, you can then reinstall llvm-libs(-svn) again afterwards.

No idea why this happens and it wasn't happening a week or two ago (when this package build LLVM 7.0) so I assume it's an issue with something in LLVM 8.

EDIT: Is this patch needed? https://bugs.archlinux.org/task/59631

Looks like it is, see https://reviews.llvm.org/D50416 - Upstream is aware of the issue and intend to push a fix, but it hasn't been committed yet. This fix is required until they do.

electropura commented on 2018-08-15 00:17

Not to my knowledge no, that will take a loong time it seems. I'm not sure about MacOS, but redhat still don't ship python3 by default so the llvm guys seem reluctant to upgrade.

kerberizer commented on 2018-08-12 17:13

@electropura, do you know if the Python bindings and other Python stuff are now also v3 compatible? Currently, we specifically make sure that python2 is used. If we could switch entirely to Python 3, that would be great indeed.

electropura commented on 2018-08-09 20:07

In addition to my earlier comment, there's no need for the python2 version of sphinx either, 'python-sphinx' works fine.

electropura commented on 2018-08-09 19:57

The python3-version of recommonmark seems to work fine, there's no need to install a boatload of python2 cruft to just build llvm.

kerberizer commented on 2018-08-09 14:01

@Enverex, @Lone_Wolf, fixed, thank you, guys!