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

Required by (128)

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 .. 31 32 33 34 35 36 37 38 39 40 41 .. 70 Next › Last »

kerberizer commented on 2017-06-13 18:17 (UTC)

@thaewrapt, indeed, I wanted to sync this with the official package for a while now. Thanks for confirming that it is in fact a pressing matter. The easiest solution would be to just add the appropriate provides/conflicts to the llvm-svn package, but I'd rather make lld a separate package like it's in "extra".

thaewrapt commented on 2017-06-13 16:43 (UTC)

It's conflicting with 'lld' package from repositories, fix this, pls.

kerberizer commented on 2017-06-03 16:52 (UTC)

@Lone_Wolf, thanks for clearing that up. I've always felt there's something not quite correct with those "replaces", but preferred to not touch them on the basis of "if it ain't broken, don't fix it". I think Trilby's explanation must be indeed why they had been added in the past. @everyone else: Apologies for being minimally active in the past few months, but work and other issues have been taking away a good deal of my time. I hope that in the summer I'll have more time to catch up with the non-critical issues: libc++, lldb, the "semi-stable", historical and compat repos (there didn't seem to be much interest in them anyway), etc.

Lone_Wolf commented on 2017-06-03 14:10 (UTC)

It seems replaces= are not needed, please remove them. https://bbs.archlinux.org/viewtopic.php?id=226809

kerberizer commented on 2017-03-22 23:57 (UTC)

[NOTICE] Bug 31610 has been fixed by r298551, so I've reenabled the LLVM regression tests. Ref.: http://llvm.org/viewvc/llvm-project?view=revision&revision=298551

kerberizer commented on 2017-03-18 08:30 (UTC)

@lahwaacz, thank again for the helpful information and feedback. I've been thinking about different solutions: let's imagine that we keep the current packages as they are, but also introduce a new one, say "llvm-libs-lite-svn", which will include _only_ the versioned libs from the current "llvm-libs-svn" and thus won't conflict with llvm-libs from extra. In that way, the people who need the very latest libLLVM (possibly also libLTO) will be able to install them, while at the same time keeping everything else LLVM-related "stock"--that is, from the official repositories. Obviously, those who also need the unversioned libs (mainly LLVMgold.so, I guess) will have to use the "ordinary" llvm-libs-svn and therefore won't be able to install llvm-libs from extra. But for them, we could still provide "llvm-libs-compat-svn", which would include only the versioned libs from the "stock" llvm-libs, so it's kind of the opposite to llvm-libs-lite-svn. Here's a brief summary, in case the above sounded confusing: * llvm-libs: the "stock" package from extra, containing both the versioned and unversioned libraries of the latest LLVM release (currently 3.9); * llvm-libs-svn: our package, as we have it now, containing both the versioned and unversioned libraries of the LLVM svn trunk (currently 5.0.0svn); * llvm-libs-lite-svn: contains _only_ the versioned libraries from 5.0.0svn; * llvm-libs-compat-svn: contains _only_ the versioned libraries from 3.9. So, the users have the following choices: * use only llvm-libs: will have access only to the 3.9 libs; * use only llvm-libs-svn: will have access only to the 5.0.0svn libs; * use llvm-libs + llvm-libs-lite-svn: will have access to all 3.9 libs + the versioned 5.0.0svn ones; * use llvm-libs-svn + llvm-libs-compat-svn: will have access to all 5.0.0svn libs + the versioned 3.9 ones. This doesn't cover all possible use cases, but I hope that it'll be able to cover most. What do you think, lahwaacz? And everyone else, of course. Feel free to comment here or in https://github.com/kerberizer/llvm-svn/issues/13.

lahwaacz commented on 2017-03-17 18:12 (UTC)

@kerberizer Yes, I have extra/mesa installed and the problem I recently encountered was asymptote failing to run, because it links to libOSMesa.so.8 which links to libLLVM-3.9.so (explicitly this version). So pretty much the same issue as #13 you mentioned: something links to an explicit version of libLLVM, but the package depends just on llvm-libs. I'm not really sure how the dynamic linking works exactly, but the libraries that the linker sees may not be the same libraries the dynamic loader sees. Especially the lookup order is important in case of multiple unversioned libraries living in different directories. See e.g. FS#51611 for a problem with vtk6 and vtk7. But since libLLVM is properly versioned, I don't see many problems here: you just need to configure the compiler (include paths + library versions, e.g. -lLLVM-5.0svn). If the libs coexist and the user wants to compile against the svn version, he will have to configure the include paths anyway so I don't see a problem with configuring also the version. But yes, the other unversioned libs are problematic... FS#51611: https://bugs.archlinux.org/task/51611

kerberizer commented on 2017-03-17 16:59 (UTC)

@lahwaacz, thanks for raising this good point again. I've been thinking about it for some time, including in https://github.com/kerberizer/llvm-svn/issues/13 as mentioned earlier. The problem is that it seems difficult to accommodate for all the different—and sometimes conflicting—needs. I'll need to do some testing with various scenarios to see what might be the optimal approach. I'm particularly worried about use cases where the "generic" libLLVM.so and libLTO.so symlinks are from the extra/llvm-libs package, but the user wants to compile against e.g. libLLVM-5.0svn.so (some compilers allow a specific library+version name, but others don't). Yet, even more complex is the gold plugin. Probably a proper solution for it would be to put it in a subdirectory, not unlike what the Debian packages do with the different LLVM versions, but, again, that's something that I probably need to test first. Just to make sure I understood you problem correctly: you use mesa from extra (i.e. not mesa-git) and it has problems with llvm-libs-svn?

lahwaacz commented on 2017-03-17 09:48 (UTC)

Would it be possible to have the llvm-svn packages installed alongside the official llvm packages? This would avoid the conflict between llvm-libs-svn and llvm-libs and the breakage of anything that links to llvm-libs but does not depend on the explicit version it links to (e.g. mesa). I'm not using llvm-svn due to mesa-git but due to features not present in 3.9 (notably better CUDA support in clang 4.0) so I would welcome if I could stay with the stable versions of those packages without any breakage (which I even noticed only after several months anyway). This will be probably much smaller problem when 4.0 is pushed to the official repos, but the same problem might come again in the future...

kerberizer commented on 2017-03-04 04:44 (UTC)

[OPINIONS NEEDED] For those who use the binary repo, I'd be happy to hear your opinion on these two issues: * https://github.com/kerberizer/llvm-svn/issues/11 * https://github.com/kerberizer/llvm-svn/issues/13 If you don't have an account on GitHub (and don't want to register one), feel free to also comment here.

« First ‹ Previous 1 .. 31 32 33 34 35 36 37 38 39 40 41 .. 70 Next › Last »