Package Details: llvm-libs-minimal-git 17.0.0_r460868.6e19eea02bbe-1

Git Clone URL: (read-only, click to copy)
Package Base: llvm-minimal-git
Description: LLVM runtime libraries, trunk version
Upstream URL:
Licenses: custom:Apache 2.0 with LLVM Exception
Provides: llvm-libs
Submitter: Lone_Wolf
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 4
Popularity: 0.000010
First Submitted: 2019-05-14 19:32 (UTC)
Last Updated: 2023-05-14 15:19 (UTC)

Required by (96)

Sources (2)

Pinned Comments

Lone_Wolf commented on 2022-11-02 11:39 (UTC)

During building you may encounter lots of coredumps, slowing build down or even dramatically reducing the responsiveness of your system.

See for solutions/workarounds .

Lone_Wolf commented on 2020-08-22 12:30 (UTC) (edited on 2020-08-22 12:31 (UTC) by Lone_Wolf)

Archlinux currently has 3 llvm git implementations

  1. this package

    • see other pinned comments for details
  2. llvm-git

    • 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
    • binary versions in chaotic aur unofficial repository
  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-08-25 12:39 (UTC) (edited on 2021-01-30 21:15 (UTC) by Lone_Wolf)

Why does this package exist ?

Llvm & aur llvm-git are intended to provide a full development environment of llvm/clang suite that can replace eachother completely (aur llvm-git adds some xtra functionality)

llvm-minimal-git is a stripped-down llvm trunk build with these goals :

  • llvm-libs-minimal-git must coexist with stable llvm-libs
  • provide what's needed for mesa trunk (it's a hard dependency for mesa-minimal-git and a possible dependeny for mesa-git)
  • provide basic llvm/clang compiler functionality on x86-64 architecture

Some of the things that are stripped out :

  • cross-compiling support
  • bindings for ocaml
  • bindings for go
  • lld , lldb and polly
  • documentation
  • examples
  • benchmarks

Maintainers (and users) should only depend on llvm-miminal-git after verifying it satisfies what they need.

Lone_Wolf commented on 2019-08-21 13:51 (UTC) (edited on 2022-11-02 11:36 (UTC) by Lone_Wolf)

When building this you are likely to encounter test failures.

Those that mention non-x86-64 and/or non-admgpu architectures are unimportant.

To prevent building abortions due to test failures, you can use --nocheck option of makepkg.

Latest Comments

1 2 3 4 5 6 7 Next › Last »

Lone_Wolf commented on 2023-05-13 18:24 (UTC)

The method to reduce what is getting build uses `ninja -t targets' . That option appears to be exclusive to ninja, for now I'm skipping it.

The commands to split clang files do seem to work, unfortunately they complicate the PKGBUILD further.

I'm currently looking into building from snapshots to see if having separate (simple) PKGBUILDs for llvm, clang & spirv-llvm-translator is worth the effort.

blackmoon3 commented on 2023-04-24 05:36 (UTC)

Hi I forked your llvm-minimal-git package and split clang from llvm.

You can take a look :

I am running with this package for 1 week now with no issues

Lone_Wolf commented on 2023-04-22 12:57 (UTC)

I looked at repo packages requiring clang and/or llvm at runtime and found very few require llvm at runtime, much more require llvm at buildtime but not at runtime.

There appear to be benefits for llvm-minimal-git users to split clang from llvm. Doing that will complicate the package_llvm-minimal-git function further, not sure how bad that will be. Need to think about this more.

blackmoon3 commented on 2023-04-17 14:32 (UTC) (edited on 2023-04-17 14:34 (UTC) by blackmoon3)

Hi I was looking at the git history of the main LLVM/CLANG PKGBUILDs and did not see that line. The clang14 PKGBUILD was uploaded sith that line when looking to the git history. I think they added that line to ship very minimal clang package, because when I look to the PKGBUILD clang14 dont even ship clang-tools-extra stuff. That line remove some analyze tools that I think is usefull for users.

My question is : Would it benefit users to trim down some tools and functionnality provided by clang in llvm-minimal-git?

Also thanks for your response about optimizing python stuff in clang! Thanks

Lone_Wolf commented on 2023-04-17 09:34 (UTC)

That line is not present in any llvm 15 PKGBUILDs, so the decision to remove those was reverted.

It helps to know that scan-build & scan-view are part of clang tools.

As for the optimize commands : They have never been used in llvm-minimal-git since it started in 2019 and no one has ever complained about it.

Both the archwiki python packaging guidelines and the python page don't mention those commands. Unless they're proven to be beneficial I treat them as a relic that was useful in the past but is no longer.

blackmoon3 commented on 2023-04-17 00:28 (UTC) (edited on 2023-04-17 01:06 (UTC) by blackmoon3)

Hi I did some research and Archlinux use LLVM_DISTRIBUTION_COMPONENTS stuff in clang14 to get rid of scan-view scan-build-py libscanbuild libear and other stuff :

They are related to python stuff when looking to the file included in clang package. The question is : Are these python stuff are needed to llvm-minimal-git? The problem is that they provide analyze functionnality

Also libear libscanbuild scan-build-py Just sit here in llvm code :

scan-view also provide some python stuff :

Other question if theyy are needed, why you choose to not optimize them with python like Arch?

blackmoon3 commented on 2023-04-16 02:12 (UTC)

Hi I will do more research for the LLVM_DISTRIBUTION_COMPONENTS stuff and keep in touch with you.

As for libexec and scan-build I will keep in touch.

For the split clang package I was talking about to build keel this PKGBUILD but move out the clang stuff in another package like spirv-llvm-translator llvm-libs and clang-libs.

Thanks in advance

Lone_Wolf commented on 2023-04-15 16:43 (UTC) (edited on 2023-04-15 16:44 (UTC) by Lone_Wolf)

Splitting llvm & clang to separate packages is not possible without switching to a snapshot approach because they need to build from the exact same sourcecode . This would mean they would no longer be VCS pacakges but instead built a specific commit. Functionally they would work similar to papadoka & oibaf PPA for ubuntu. Users would depend on the maintainer to update the package.

(The separate libclc package works because libclc is actually an independent project that uses llvm but could be (and in the past was) developed independently.)

scan-build + folders libear & libscanbuild : I don't know what they are used for and why they should be available at runtime.

The libexec stuff is already moved to another location in the PKGBUILD, and for them the same Q : why should they be in clang-libs ?

As for the LLVM_DISTRIBUTION_COMPONENTS stuff : I've noticed it when gentoo started using it a few years ago and it's definitely an interesting approach.

There are a few reasons I am reluctant to use it :

  • I don't understand which components are left out and especially why. I have not been able to find an explanation for the choices made in the code.
  • When I started llvm-minimal-git I didn't include the static libraries but was asked to put them back almost immediately.
  • llvm-minimal-git already disables many parts of the code and targets very few architectures. Is the gain from using LLVM_DISTRIBUTION_COMPONENTS worth it ?

blackmoon3 commented on 2023-04-15 15:47 (UTC)

Also you shoud integrate these change from Archlinux package

LLvm :


I incorporate these commit in on line in my PKGBUILD here :


blackmoon3 commented on 2023-04-15 15:38 (UTC)

Also thanks addings clang-libs based on my comment :)