Package Base Details: lib32-llvm-git

Git Clone URL: https://aur.archlinux.org/lib32-llvm-git.git (read-only, click to copy)
Keywords: clang git llvm
Submitter: yurikoles
Maintainer: Lone_Wolf (rjahanbakhshi)
Last Packager: rjahanbakhshi
Votes: 12
Popularity: 0.019078
First Submitted: 2019-01-11 15:50
Last Updated: 2021-01-27 18:01

Latest Comments

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

yurikoles commented on 2015-11-27 04:02

I'm unable to install this pacage with yaourt, as it tries to build single package.

kerberizer commented on 2015-11-05 16:11

Also, please note that the libLTO.so version symlinks are not installed any more.

kerberizer commented on 2015-11-05 15:51

[NOTICE] The PKGBUILD has been updated to reflect the changes from r251411 and r252093 in upstream. Using an old PKGBUILD will lead to errors like this:

error: failed to commit transaction (conflicting files)
/usr/lib32/libLLVM-3.8svn.so exists in both 'lib32-llvm-libs-svn' and 'lib32-llvm-svn'

kerberizer commented on 2015-10-10 16:13

[NOTICE] Shared library fixed

The critical bug with LLVM not exporting the expected symbols seems to have been fixed completely upstream, so I've removed the last custom patch. Keep this in mind if you notice any "undefined reference" errors.

References:
* https://github.com/kerberizer/llvm-svn/issues/2
* https://llvm.org/bugs/show_bug.cgi?id=24157
* http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-shlib/CMakeLists.txt?r1=246918&r2=249862&diff_format=h

kerberizer commented on 2015-10-09 11:10

[HEADS UP] Users of `llvm-svn`, `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 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) due to a recent change in the LLVM shared library.

If Mesa is not recompiled, with the new llvm-svn packages you'll most likely face errors like this:

gbm: Last dlopen error: /usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: _ZN4llvm21SymbolTableListTraitsINS_11InstructionENS_10BasicBlockEE13addNodeToListEPS1_

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

kerberizer commented on 2015-09-06 19:27

[HEADS UP] Dependency change

As discussed earlier, lib32-llvm-svn has been changed to depend on llvm-svn, instead of on llvm. For most of you, who have llvm-svn installed anyway, this is NOT going to change anything. For those few, however, who may be using lib32-llvm-svn alongside llvm from the official extra repo, have in mind that you'll have to switch to llvm-svn too, which is probably a good idea anyway.

kerberizer commented on 2015-09-06 13:11

[HEADS UP] Rebuild required

I've committed the change that should fix the shared library breakage. This might require some action on your side, namely:

* If you build the packages yourself and have last rebuilt them more recently than 08:30 AM UTC yesterday, Sept 5th, please do rebuild them again now.

* If you use the binary repo and have last updated your packages from the repo more recently than 09:00 AM UTC yesterday, Sept 5th, please update them again.

As usual, please let me know if you find any problems, and especially if they are of the "undefined reference" type when linking to libLLVM, please report them here: https://github.com/kerberizer/llvm-svn/issues/2

kerberizer commented on 2015-09-06 11:18

[WARNING] The shared library seems broken at the moment, with many symbols not being exported. For more information, please see the comments for the llvm-svn package. A fix is on its way.

https://aur.archlinux.org/pkgbase/llvm-svn/

kerberizer commented on 2015-08-22 19:22

@Lone_Wolf, thanks! Those are good points and I, too, am increasingly leaning towards keeping the things consistent. However, I'll be travelling tomorrow early morning and will be away for a few days, so it's probably best not to touch the build system right now, as it will need some readjustment. I'll look into this when I'm back home. And, in the meantime, someone else might chime in as well.

@oxalin, I see. If anything interesting comes out from your case upstream, don't forget to post it here. Might come in handy anyway. :)

oxalin commented on 2015-08-22 16:59

@kerberizer, no it's not that bug.

I wished there would be a way to detect automatically the number of cores available though instead of manually setting it. Anyway, I agree with you that we can change/set the value in makepkg.conf.