Package Base Details: lib32-llvm-git

Git Clone URL: https://aur.archlinux.org/lib32-llvm-git.git (read-only)
Keywords: clang git llvm
Submitter: yurikoles
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 11
Popularity: 0.069955
First Submitted: 2019-01-11 15:50
Last Updated: 2019-11-02 00:44

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

kerberizer commented on 2016-11-07 19:50

[NOTICE] Update for the LLVM r286062 issue with Mesa is now in code review: https://patchwork.freedesktop.org/series/14932/

Edit: Updated the link.

kerberizer commented on 2016-11-07 14:46

[HEADS UP] LLVM r286062 breaks Mesa

If you use llvm-svn with Mesa, particularly for the AMD open source driver, DO NOT upgrade LLVM to version >=r286062. Upgrading will not only break the existing driver, but will also prevent you from building Mesa altogether (in both cases there will be error messages related to missing LLVMAddFunctionAttr).

If you have already upgraded to a version >=r286062, here are some possible solutions:
1. Don't restart X: everything should mostly keep running, since the older shared lib has already been loaded in memory. A fix for Mesa should emerge in the meantime, probably in a day or two at most.
2. Return to an older LLVM version: if you don't regularly clear /var/cache/pacman/pkg, you should be able to find there package versions earlier than r286062.
3. Switch to llvm/mesa from the official repositories. This may be somewhat tricky, depending on what exact packages you had installed. Try replacing as much as possible of the installed llvm-svn/mesa-git packages with their llvm/mesa counterparts. Remove the -svn/-git packages that don't have an equivalent 'provides' in the official repos. Of course, this might break some functionality for you.

I'll also consider keeping older versions of the llvm-svn* packages in the binary repo as a backup.

Ref: https://github.com/llvm-mirror/llvm/commit/4a6fc8bacf11d8066da72cf8481467167877ed16

spacejoe commented on 2016-10-24 01:06

By the way, I wasn't using pacaur, despite de folder path. I downloaded the tarball and ran makepkg. I'll try your suggestion, though. Thank you.

kerberizer commented on 2016-10-23 19:19

@spacejoe, I cannot reproduce the problem you describe on the system that constantly rebuilds the packages automatically. I do see however that you're using pacaur, an AUR helper. I'm afraid this isn't recommended and therefore is not supported, because LLVM/Clang is a fairly complex package. I'd suggest trying to build in a clean chroot as explained in the link in the pinned comment. Please let me know if that works.

kerberizer commented on 2016-10-23 19:15

[PINNED] IMPORTANT INFORMATION // PLEASE READ CAREFULLY

Please check the following page for information on: possible problems with this package; recommendations on how to build it; * availability of binary packages.

https://github.com/arch-llvm/lib32-llvm-svn

You may also use it for bug reports and pull requests.

spacejoe commented on 2016-10-23 16:52

I keep getting this error when building the package

[ 4%] Building AttributesCompatFunc.inc...

/home/ricardo/.cache/pacaur/lib32-llvm-svn/src/llvm/lib/IR/AttributesCompatFunc.td:1:9: error: Could not find include file 'llvm/IR/Attributes.td'
include "llvm/IR/Attributes.td"
^
/home/ricardo/.cache/pacaur/lib32-llvm-svn/src/llvm/lib/IR/AttributesCompatFunc.td:1:9: error: Unexpected input at top level
include "llvm/IR/Attributes.td"


Sometimes it goes a little furthen in the building and stops at some other file, same error.

kerberizer commented on 2016-07-13 15:44

@Enverex, most likely you have llvm-ocaml{,-svn} installed on the build system. Either uninstall this package prior to building or, better yet, build in a clean chroot. Please let me know if that solves your problem.

Enverex commented on 2016-07-13 12:41

Doesn't built here:

findlib: [WARNING] Interface llvm.cmi occurs in several directories: /home/arcade/build/pkg-autobuild/lib32-llvm-svn/src/build/bindings/ocaml/llvm, /usr/lib/ocaml
findlib: [WARNING] Interface llvm_target.cmi occurs in several directories: /home/arcade/build/pkg-autobuild/lib32-llvm-svn/src/build/bindings/ocaml/target, /usr/lib/ocaml
File "/home/arcade/build/pkg-autobuild/lib32-llvm-svn/src/build/bindings/ocaml/executionengine/llvm_executionengine.ml", line 1:
Error: The files /usr/lib/ocaml/llvm_target.cmi and llvm_executionengine.cmi
make inconsistent assumptions over interface Llvm_target
1 error(s) encountered

kerberizer commented on 2016-02-16 18:16

[HEADS UP] Users of "{lib32-,}llvm-svn", "{lib32-,}mesa-git" and AMD video cards MUST recompile Mesa

If __all__ of the following are true for you...
* you use an AMD video card with the open source drivers,
* you use "{lib32-,}mesa-git" from AUR, with version < g0bba5ca,
* you use "{lib32-,}llvm-svn" from AUR, with version >= r260919,
...then you __must__ recompile the Mesa packages (or possibly upgrade again from the "mesa-git" binary repo you use).

The reason is explained in this Mesa commit:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=0bba5ca468cdcd1f6f9bb6736c8a75e43fbe0cd5

If Mesa is not recompiled, you'll face errors of the type:

libGL: dlopen /usr/lib/xorg/modules/dri/radeonsi_dri.so failed (/usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: LLVMAddTargetData)

Please note that with the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

kerberizer commented on 2016-01-14 10:35

[HEADS UP] Users of `{lib32-,}llvm-svn`, `{lib32-,}mesa-git` and AMD video cards MUST recompile Mesa

If ALL of the following are true for you:
* you use an AMD video card with the open source drivers,
* you use `{lib32-,}mesa-git` from AUR,
* you use `{lib32-,}llvm-svn` from AUR,
* you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo,
then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use).

The reason is the recent branching of LLVM/Clang 3.8 and bumping the development version to 3.9, which also affects the shared library version. If Mesa is not recompiled, with the new {lib32-,}llvm-svn packages you'll face errors of the type:

gbm: Last dlopen error: libLLVM-3.8svn.so: cannot open shared object file: No such file or directory
(EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (libLLVM-3.8svn.so: cannot open shared object file: No such file or directory)

Please note that for the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.