Package Details: lib32-llvm-git 19.0.0_r495961.17b86d5978af-1

Git Clone URL: https://aur.archlinux.org/lib32-llvm-git.git (read-only, click to copy)
Package Base: lib32-llvm-git
Description: Collection of modular and reusable compiler and toolchain technologies (32-bit, git)
Upstream URL: https://llvm.org/
Keywords: clang git llvm
Licenses: custom:Apache 2.0 with LLVM Exception
Conflicts: lib32-clang, lib32-llvm
Provides: aur-lib32-llvm-git, lib32-clang, lib32-clang-git, lib32-llvm
Submitter: yurikoles
Maintainer: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 12
Popularity: 0.000062
First Submitted: 2019-01-11 15:50 (UTC)
Last Updated: 2024-04-17 08:43 (UTC)

Required by (30)

Sources (1)

Pinned Comments

Latest Comments

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

kerberizer commented on 2015-11-05 15:51 (UTC)

[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 (UTC)

[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 (UTC)

[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 (UTC)

[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 (UTC)

[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 (UTC)

[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 (UTC)

@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 (UTC)

@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.

Lone_Wolf commented on 2015-08-22 13:43 (UTC)

For programs that have a 64-bit and a 32-bit version, the multilib version is often the 32-bit version just compiled on a different architecture. In these cases, the multilib version is standalone. Other programs use parts from their 64-bit "parent" in their multilib version. I'm certain (building lib32-mesa-git against stock mesa was one of my biggest blunders) Mesa is in the 2nd category , that's why lib32-mesa-git depends on mesa-git . I'm not sure about llvm, but official lib32-llvm does depend on 64-bit llvm.

kerberizer commented on 2015-08-22 12:58 (UTC)

@Lone_Wolf > lib32-llvm-svn depends on llvm and this should be llvm-svn instead Yes, I know this, and was thinking about it a while ago. It's quite likely better/safer to set a dependency on llvm-svn, but I thought there might be people who actually do want to have the stable LLVM on native 64-bit and just use the SVN version for multilib. At the same time, llvm-svn provides 'llvm' dependency, so there shouldn't be unnecessary pulls when llvm-svn is already installed. The only case of confusion that I see is if someone decides to install lib32-llvm-svn without having any LLVM installed previously, and then decides to install llvm-svn, which would then conflict with the already pulled in llvm from extra; I guess such cases would be rather unlikely though. As a matter of fact, I'm not even sure if that dependency is really necessary: it was there when I took over the package and I didn't quite have the time to properly test it. Namcap states it's superfluous and that's exactly what I would expect myself. So, perhaps I might as well remove it completely. Any thoughts?

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