Package Base Details: llvm-svn

Git Clone URL: https://aur.archlinux.org/llvm-svn.git (read-only)
Keywords: clang lld lldb llvm
Submitter: None
Maintainer: kerberizer (Lone_Wolf)
Last Packager: kerberizer
Votes: 106
Popularity: 2.756385
First Submitted: 2007-08-02 07:15
Last Updated: 2018-08-23 13:04

Pinned Comments

kerberizer commented on 2016-08-11 00:39

[PINNED] IMPORTANT INFORMATION // PLEASE READ CAREFULLY

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

https://github.com/arch-llvm/llvm-svn

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

Latest Comments

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

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.

see https://github.com/LW-archlinux/llvm-svn

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

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