Package Details: llvm-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: LLVM development version. includes clang and many other tools
Upstream URL: https://llvm.org/
Keywords: clang git lld lldb llvm polly
Licenses: custom:Apache 2.0 with LLVM Exception
Conflicts: clang, compiler-rt, lld, lldb, llvm, polly
Provides: aur-llvm-git, clang, clang-git, compiler-rt, compiler-rt-git, lld, lld-git, lldb, lldb-git, llvm, polly, polly-git
Submitter: yurikoles
Maintainer: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 118
Popularity: 0.005806
First Submitted: 2018-12-05 13:56 (UTC)
Last Updated: 2024-04-17 08:17 (UTC)

Required by (2230)

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

kerberizer commented on 2016-06-21 18:45 (UTC)

[NOTICE] There is a new version of the D18035 patch. However, in the author's own words, "this patch set was not tested extensively on real world apps so it might have be worse than previous one". For this reason, for the time being I'm _not_ going to update our package with it. At the same time, just like the author of the patch I do urge those of you who use Clang more actively to test the patch on your own and report back any issues in the thread here: http://reviews.llvm.org/D18035

gentoofu commented on 2016-06-15 01:17 (UTC)

The problem I was having may have been fixed with the new version of make that just came out of stable repo.

kerberizer commented on 2016-06-11 17:45 (UTC)

It also seems that one of the regression tests, 'LLVM :: tools/gold/X86/thinlto_alias.ll', is failing when building on i686. I don't know how many of you actually build this on 32-bit systems, and so how many of you are affected. Considering that nobody has complained yet, probably not too many. I'll take a look at it at some point, but recently I've been quite busy with my day job, so it might take some time. In other words, if some of you _are_ affected, please bug me harder (unless you can even find the cause yourself).

kerberizer commented on 2016-06-10 22:14 (UTC)

[NOTICE] I've finally fixed the problem with lib32-llvm-svn. This is the only reason for the version bump; llvm-svn is not changed in any way. The good news is also that the binary repo will begin updating regularly (i.e. every 6 hours) again. Sorry this took me so awfully long.

kerberizer commented on 2016-06-01 13:24 (UTC)

@gentoofu, thanks for the feedback. I'm also really glad that the examples have been useful to you. Probably I'll consider compiling some kind of FAQ on using this PKGBUILD to put into a sticky comment. Meanwhile, a notice to everyone who compiles lib32-llvm-svn: there seems to be some bug with libffi. For some reason, an attempt is made to link the 32-bit LLVM shared library to the 64-bit libffi.so. I suspect this has something to do with the recent Cmake-related commits to LLVM, but I'll have to investigate further.

gentoofu commented on 2016-06-01 05:48 (UTC)

kerberizer, I find your instructions to be more useful than the wiki's; thanks. llvm-svn 3.9.0svn_r271360-1 builds fine on clean chroot.

kerberizer commented on 2016-05-30 14:25 (UTC)

@LinguinePenguiny, do you build in a clean chroot? I did some additional testing on my own desktop system (which, BTW, happens to also be an FX-8350), but I couldn't reproduce the problem, I'm afraid. For me, the testing succeeds even when using makepkg outside of a clean chroot. However, each system setup can be specific enough to cause unique problems, which is why I always recommend building in a clean chroot. Just in case someone finds this information helpful, here are some example commands how to build in a clean chroot. I still advise consulting the Arch Wiki though.[1] The example (it's actually a crude excerpt from the build script that I use for the binary repo) is meant to allow building lib32-llvm-svn too, hence why gcc-multilib is used. It takes advantage of multiple cores when building and compressing (the example here is tailored to an 8-core/threads system). The user's ccache cache is utilised as well, so frequent rebuilds can be much faster. If you don't sign your packages, omit the lines mentioning PACKAGER and GPGKEY, otherwise they need to be set correctly. The chroot ("${x86_64_chroot}") is best set up in /tmp, but this requires a lot of RAM (most likely at least 32 GB, since /tmp is by default half the size of the physical RAM detected); second best solution is on an SSD. The latter goes for ~/.ccache as well. $ cd /path/to/where/llvm-svn/is/cloned $ x86_64_chroot="/chroot/x86_64" $ sudo mkdir -p "${x86_64_chroot}/root" $ sudo /usr/bin/mkarchroot \ -C /usr/share/devtools/pacman-multilib.conf \ -M /usr/share/devtools/makepkg-x86_64.conf \ -c /var/cache/pacman/pkg \ "${x86_64_chroot}/root" \ base-devel ccache $ sudo /usr/bin/arch-nspawn "${x86_64_chroot}/root" /bin/bash -c "yes | pacman -Sy gcc-multilib" $ sudo /usr/bin/arch-nspawn "${x86_64_chroot}/root" /bin/bash -c \ "echo -e \"CCACHE_DIR='/.ccache'\nXZ_DEFAULTS='--threads=8'\" >>/etc/environment ; \ sed \ -e 's/^#MAKEFLAGS=.*$/MAKEFLAGS=\"-j9\"/' \ -e '/^BUILDENV=/s/\!ccache/ccache/' \ -e 's/^#PACKAGER=.*$/PACKAGER=\"Some One <someone@somewhere.com>\"/' \ -e 's/^#GPGKEY=.*$/GPGKEY=\"0x0000000000000000\"/' \ -i /etc/makepkg.conf" $ sudo /usr/bin/makechrootpkg -c -d ~/.ccache:/.ccache -r "${x86_64_chroot}" It's advisable to always start this from scratch, i.e. don't reuse the old chroot, but create it anew for each build (it uses the local pacman cache, so doesn't waste bandwidth, and if located in /tmp or on an SSD, is pretty fast). ---- 1. https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

LinguinePenguiny commented on 2016-05-30 09:54 (UTC)

I do also get that build failure, and have for a few weeks. I run an FX-8350 CPU. http://pastebin.com/yu9VeefG (1 month expiry time from May 30th, 2016)

kerberizer commented on 2016-05-29 19:48 (UTC)

@gentoofu, could you possibly try building in a clean chroot? https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

gentoofu commented on 2016-05-29 19:09 (UTC)

Yes. I also tried changing the PKGBUILD to pkgver=3.9.0svn_r271186 and use makepkg, and I get the same error.

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