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.010693
First Submitted: 2018-12-05 13:56 (UTC)
Last Updated: 2024-04-17 08:17 (UTC)

Required by (125)

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 .. 35 36 37 38 39 40 41 42 43 44 45 .. 70 Next › Last »

okabekudo commented on 2016-07-24 19:19 (UTC) (edited on 2016-07-24 19:20 (UTC) by okabekudo)

make[3]: *** No rule to make target '/build/llvm-svn/src/llvm/include/mlvm/Target/TargetOpcodes.h', needed by 'lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600EmitClauseMarkers.cpp.o'. Stop. make[2]: *** [CMakeFiles/Makefile2:5004: lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs.... [ 79%] Built target LLVMMipsAsmParser [ 79%] Built target LLVMMipsDesc [ 79%] Built target LLVMMSP430CodeGen [ 82%] Built target LLVMMipsCodeGen [ 85%] Built target LLVMHexagonCodeGen make[1]: *** [CMakeFiles/Makefile2:111320: docs/CMakeFiles/ocaml_doc.dir/rule] Error 2 make: *** [Makefile:22648: ocaml_doc] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /home/michel/chroot/michel/build Getting this right now. Probably not due to the makeflags though.

kerberizer commented on 2016-07-24 17:47 (UTC)

@okabekudo, I think I understand what you might be refererring to: there used to be some complications with the OCaml bindings, which weren't necessarily caused by the multithreaded building, but may had been exacerbated by it. This has however been finally fixed in December, if I remember correctly. So, yes, please do test and let me know if you still find problems.

okabekudo commented on 2016-07-24 17:16 (UTC)

@keberizer Well in the past that means atmost 8 months ago it would break with makeflags -j. So I haven't tried since then. So that was just a generic question so far. But if you say it worked since you took over the maintainership I will test it now and report back.

kerberizer commented on 2016-07-24 17:05 (UTC)

@okabekudo, this package __does__ build with parallel make threads as many as 64, and as far as I can remember it has been that way ever since I took over the maintainership a year ago. I do see there used to be such problems in the past, but the last relevant comments seem to be from 2013. So, do you have a problem with the PKGBUILD __now__, or was it just a generic question? Thank you.

okabekudo commented on 2016-07-24 16:34 (UTC) (edited on 2016-07-24 16:35 (UTC) by okabekudo)

Does this still break when using makeflags -j? If it does please add options=('!makeflags') to the PKGBUILD. It's a pain editing either my makepkg.conf or the PKGBUILD everytime I update llvm-svn. And you probably know this it takes hours building llvm-svn. So it's crucial to get the paralell jobs fixed.

kerberizer commented on 2016-07-21 15:40 (UTC)

[NOTICE] Probably you've noticed that LLVM is now at version 4.0.0svn. If you're using it for Mesa, DON'T forget to also rebuild the latter after you update LLVM. The reason is that the name of the shared lib has also changed and the dynamic linker would have trouble finding the old file. Alternatively, you may temporarily create a symlink from /usr/lib/libLLVM-3.9svn.so to /usr/lib/libLLVM-4.0svn.so, which can be especially helpful if you can't get to the desktop because of the problem. Once Mesa--and any other applications that had been linked to the LLVM shared lib--are recompiled however, it's better to remove that symlink.

kerberizer commented on 2016-07-21 15:35 (UTC)

@Enverex, tests do fail from time to time. Currently, we don't apply any local modifications to the code that might have otherwise been the cause, so these problems usually get resolved upstream within a day or two. If for some reason you do need to use the current code ASAP, temporarily comment out or add "|| true" to the make check lines.

Enverex commented on 2016-07-21 15:28 (UTC)

Doesn't compile for me as it fails one of the tests: FAIL: Clang :: CodeGen/2008-03-24-BitField-And-Alloca.c (1332 of 9662)

kerberizer commented on 2016-06-30 12:56 (UTC)

[NOTICE] As expected, D18035 has finally been committed today and so I've removed the patch from our package. I'm also copying here the patch author's request for additional testing: "I decided to commit this patch without waiting for GCC response to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71712 (that is last compatibility issues in comparison with GCC6) so more people could test Clang implementation of ABI tags on real apps and report issues if any. All, please let me know (file bug and add me in CC) if you observe any issues with abi_tag implementation in Clang." http://reviews.llvm.org/D18035

kerberizer commented on 2016-06-29 17:25 (UTC) (edited on 2016-06-29 17:27 (UTC) by kerberizer)

[NOTICE] The old version of D18035 was no longer applying cleanly, so I updated it to the very latest (and probably final before merging) version from today: http://reviews.llvm.org/D18035 edit: missed a preposition

« First ‹ Previous 1 .. 35 36 37 38 39 40 41 42 43 44 45 .. 70 Next › Last »