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

Required by (129)

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 .. 43 44 45 46 47 48 49 50 51 52 53 .. 70 Next › Last »

kerberizer commented on 2015-10-01 09:15 (UTC)

@JackM, I'm very reluctant to make this switch right now, because in my view it will actually be detrimental to the users. The reason is that the SSL/TLS configuration on llvm.org is particularly bad. Just look at what the Qualys SSL tester gives as a result: F(ail) with lots and lots of severe problems. https://www.ssllabs.com/ssltest/analyze.html?d=llvm.org As a security officer, I've learned to always consider a false sense of security as a much worse option than no security at all. I'd rather have the users _know_ that they can fall a victim of, say, man-in-the-middle attack by using a non-encrypted connection, and thus be ready to check the source files validity by other means or at least be wary, rather than having them feel like they have nothing to worry about and then do fall a victim because of a badly configured encryption on the server side on which they have no control. I understand there might be other views on this issue, and I'd be really glad to hear them.

JackM commented on 2015-09-30 22:53 (UTC)

please change download url htttps source=( - "${_pkgname}::svn+http://llvm.org/svn/llvm-project/llvm/trunk" - 'clang::svn+http://llvm.org/svn/llvm-project/cfe/trunk' - 'clang-tools-extra::svn+http://llvm.org/svn/llvm-project/clang-tools-extra/trunk' - 'compiler-rt::svn+http://llvm.org/svn/llvm-project/compiler-rt/trunk' + "${_pkgname}::svn+https://llvm.org/svn/llvm-project/llvm/trunk/" + 'clang::svn+https://llvm.org/svn/llvm-project/cfe/trunk/' + 'clang-tools-extra::svn+https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/' + 'compiler-rt::svn+https://llvm.org/svn/llvm-project/compiler-rt/trunk/'

kerberizer commented on 2015-09-22 12:16 (UTC)

Sorry for not replying earlier, guys, but I've been abroad for a couple of days and I'm still catching up with things. @Meistache, are you still getting your error? As I've mentioned earlier, transient build errors happen from time to time due to the very high commit activity, but they are also very quickly resolved. @Eriner, it seems that the custom patch for LLVM bug 24157 is somehow not applied in your case. Could you please check if your PKGBUILD is up to date and that the llvm_tools_shlib_CMakeLists.patch does get applied cleanly during prepare(). Without this patch, it's expected to see the errors you report.

Eriner commented on 2015-09-21 05:54 (UTC)

@Meistache try to remove any previous packages installed by llvm-svn and rebuild. Is anyone else getting this error building mesa-git? https://gist.github.com/Eriner/195b61a1b8a5e0d954a0 The error above seems to only occur when building llvm-svn from source; it does not occur when using your repo, @kerberizer. I know the recommendation is to build in a clean chroot, but does that really matter if I remove all the related llvm-svn packages? (obviously it does; I'm just ignorant as to why)

Meistache commented on 2015-09-20 22:47 (UTC)

Hello kerb, just can't go through it, any ocaml binding I should check? [ 31%] Building CXX object lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o In file included from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineBasicBlock.h:18:0, from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineDominators.h:19, from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachinePostDominators.h:18, from /home/meistache/AUR/llvm-libs-svn/src/llvm/lib/CodeGen/MachinePostDominators.cpp:15: /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineInstr.h:321:3: internal compiler error: in set_inherited_value_binding_p, at cp/name-lookup.c:3003 iterator_range<mop_iterator> defs() { ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/build.make:1694: recipe for target 'lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o' failed make[3]: *** [lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o] Error 1 CMakeFiles/Makefile2:871: recipe for target 'lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/all' failed make[2]: *** [lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/all] Error 2 CMakeFiles/Makefile2:50481: recipe for target 'docs/CMakeFiles/ocaml_doc.dir/rule' failed make[1]: *** [docs/CMakeFiles/ocaml_doc.dir/rule] Error 2 Makefile:10415: recipe for target 'ocaml_doc' failed make: *** [ocaml_doc] Error 2

kerberizer commented on 2015-09-09 13:00 (UTC)

[HEADS UP] Missing compiler-rt added and a package group created * As reported by @guardian, the compiler-rt set of runtime libraries have been missing entirely from the packages. They are part of the official "clang" package in the extra repo, but here I've decided to put them in a separate package, "clang-compiler-rt-svn", as this seems to be the practice upstream. IMPORTANT: If you use Clang's sanitizer instrumentation or any other feature that requires the compiler-rt libraries, you MUST install the "clang-compiler-rt-svn" package. It'll also be available from the binary repo shortly. * All packages have now been made part of a group, "llvm-toolchain-svn". This should allow for easy installation of the whole LLVM toolchain, at least for those who use the binary repo. Instead of "pacman -Sy llvm-svn llvm-libs-svn clang-svn bla-bla-bla...", you can now use just "pacman -Sy llvm-toolchain-svn". The only notable exception are the OCaml bindings that, if needed, must still be installed separately.

kerberizer commented on 2015-09-09 10:38 (UTC)

@guardian, good catch, thank you! I'll look into this asap. Meanwhile, if you have an account on GitHub, could you please report the problem there as well? https://github.com/kerberizer/llvm-svn/issues On a side note, it seems that a free-text notes field is badly needed for AUR: the information about binary repos, known bugs, where to report new ones, etc. could go there.

guardian commented on 2015-09-09 07:42 (UTC)

I'm not sure it's the proper place to report my issue but I don't recall how I ended up learning about https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn I installed clang-analyzer-svn-3.8.0svn_r247119-1. Then I created a simple C program that does nothing in main.c Then invoking clang -fsanitize=address main.c reports: /usr/bin/ld: cannot find /usr/bin/../lib/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) In fact there's no /usr/lib/clang/3.8.0/lib on my system.

kerberizer commented on 2015-09-07 14:22 (UTC)

@yurikoles, I think I got what you had in mind. You want to have the opportunity to build -- with this PKGBUILD -- not just the latest trunk/master, but also specific releases and tagged versions, right? So the "branch" variable that you mention would be set by the user to the desired code and the source URLs in the PKGBUILD would not end in hard-coded "trunk", but "${branch}", correct? This is quite an interesting idea, indeed. However, I'm also afraid that it isn't going to work that well too. The problem is that building LLVM is not completely straightforward. For example, we used up until very recently some rather dirty tricks to make it export the necessary symbols in the shared library. With the latest changes upstream, we managed to get rid of most of those hacks. But if you try building even the latest release instead of the trunk, then you must __again__ apply those tricks. So should the PKGBUILD contain and apply those hacks -- necessary for earlier code -- or should it not, which is required for trunk? In other words, the PKGBUILD is tailored __specifically__ to the trunk/master code. It might indeed work if you try building some older code, e.g. a release, but most likely it will fail or, worse yet, will silently produce problematic binaries/libraries. While it would be theoretically possible to support internal logic accounting for the specifics of the countless number of branches and tags that a user might want to build, neither do I have the resources to maintain such a complicated PKGBUILD, nor do I find it particularly efficient from maintainer's point of you. And in the context of AUR, it would be much better to have a separate package for each historic release anyway. Sorry if I disappoint you, and please do let me know if I haven't got your idea right.

« First ‹ Previous 1 .. 43 44 45 46 47 48 49 50 51 52 53 .. 70 Next › Last »