Package Details: llvm-libs-git 18.0.0_r484887.953ae94149f0-1

Git Clone URL: https://aur.archlinux.org/llvm-git.git (read-only, click to copy)
Package Base: llvm-git
Description: runtime libraries for llvm-git
Upstream URL: https://llvm.org/
Keywords: clang git lld lldb llvm polly
Licenses: custom:Apache 2.0 with LLVM Exception
Conflicts: llvm-libs
Provides: aur-llvm-libs-git, llvm-libs
Submitter: yurikoles
Maintainer: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 118
Popularity: 0.010051
First Submitted: 2018-12-05 13:56 (UTC)
Last Updated: 2024-04-17 08:17 (UTC)

Required by (127)

Sources (2)

Pinned Comments

Lone_Wolf commented on 2021-08-16 11:26 (UTC)

When you have this package installed applications that are built against repo-llvm/clang WILL fail unless they are rebuild against this package.

This includes QTCreator, kdevelop , mesa, intel-compute-runtime, gnome-builder to name a few.

Lone_Wolf commented on 2020-08-22 12:18 (UTC) (edited on 2021-02-06 12:51 (UTC) by Lone_Wolf)

Archlinux currently has 3 llvm git implementations

  1. This package

    • It aims to provide a full llvm/clang compiler environment for development purposes.
    • Supports cross-compiling , bindings for external stuff (python, ocaml etc) , and some things not in extra-llvm.
    • intended to be used with archlinux core,extra & community repos
    • CONFLICTS with extra llvm/clang packages
    • Currently there's no repo with binary versions

  2. llvm-minimal-git

    • focuses on providing stuff needed for AUR mesa-git. Doesn't support cross-compiling or any bindings for external stuff like ocaml & python.
    • intended to be used with archlinux core,extra & community repos
    • compatible with extra llvm/clang packages
    • no repo with binary versions

  3. packages created & maintained by Lordheavy, an arch developer

    • intended to be used with archlinux testing repos
    • sometimes has problems on systems where testing repos are disabled
    • uses same package structure as llvm/clang in official repos
    • source
    • binary versions in LordHeavys unoffical repo

Lone_Wolf commented on 2019-04-12 20:41 (UTC) (edited on 2019-12-16 22:45 (UTC) by Lone_Wolf)

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 1 .. 24 25 26 27 28 29 30 31 32 33 34 .. 70 Next › Last »

goddessfreya commented on 2018-08-23 11:21 (UTC) (edited on 2018-08-23 11:29 (UTC) by goddessfreya)

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 (UTC)

@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 (UTC) (edited on 2018-08-16 11:34 (UTC) by Enverex)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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

Lone_Wolf commented on 2018-08-07 17:13 (UTC)

It is a newly introduced makedep, just add python2-recommonmark to makedepends array.

Enverex commented on 2018-08-07 11:51 (UTC)

"python-recommonmark" (not sure if it's python or python2) appears to be a dependency. Without it, the build fails with:

Extension error: Could not import recommonmark.parser (needed for source parser) (exception: No module named recommonmark.parser)

« First ‹ Previous 1 .. 24 25 26 27 28 29 30 31 32 33 34 .. 70 Next › Last »