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.000061
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 »

Lone_Wolf commented on 2015-08-22 12:33 (UTC)

lib32-llvm-svn depends on llvm and this should be llvm-svn instead.

kerberizer commented on 2015-08-19 09:01 (UTC)

Thank you for the kind words, guys. I really appreciate your comments and suggestions. Lone_Wolf is right about makepkg setting the number of parallel threads according to the setting in makepkg.conf. In fact, the automatic build system that I've set up for the binary repo uses a value as high as `MAKEFLAGS="-j33"', since it has 32 cores. For those who prefer to build the packages themselves, and do this frequently, I'd also strongly recommend using ccache -- but then again, most possibly you already do, since it's quite the obvious thing. Speaking of the binary repo, I probably should've announced that the builds now are indeed automatic, every 6 hours (starting from 03:00 AM UTC). It's probably an overkill user-wise, but considering the commit activity, if something breaks badly and consistently, this should in theory help narrow down the possible reasons. Please let me know if you have any thoughts on this, e.g. if someone is pissed off with the constant updates and would prefer an e.g. daily or even weekly repo (that's not hard to set up at all). BTW, don't forget that you can also use GitHub if you have specific issues... https://github.com/kerberizer/lib32-llvm-svn/issues ...and especially if you want to suggest a patch... https://github.com/kerberizer/lib32-llvm-svn/pulls @oxalin, is this the bug you were referring to?... https://llvm.org/bugs/show_bug.cgi?id=23063

Lone_Wolf commented on 2015-08-19 08:02 (UTC)

Oxalin, arch users should make those changes in /etc/makepkg.conf , not in individual packages. Or doesn't llvm-svn make honor locally set makeflags ? Default value for archlinux is 2 , useful for single core processors. -j1 is only needed for progams that fail building with j2 or higher, and those are rare nowadays. relevant snippet from my /etc/makepkg.conf : #-- Make Flags: change this for DistCC/SMP systems #MAKEFLAGS="-j2" MAKEFLAGS="-j9"

oxalin commented on 2015-08-19 03:12 (UTC)

@kerberizer: moving from autotools to cmake was indeed not that hard once you found the options. I was struggling with some targets though: some are failing if you don't tweak your options correctly (like you said in some of your commit's descriptions). I'm still working on an issue reported to the LLVM dev team on the matter. By the way, great job. I'd like to suggest a small modification to speed up the build process on multicore system: build() { + _cpucount=$(grep -c processor /proc/cpuinfo 2>/dev/null) + _jc=$((${_cpucount:-1})) [...] - make + make -j $_jc [...] You could also add the "-j $_jc" to "make -j $_jc ocaml_doc"

Eriner commented on 2015-08-11 06:45 (UTC)

Thanks for your hard work @kerberizer

kerberizer commented on 2015-08-06 20:40 (UTC)

[HEADS UP] Manual intervention required: version scheme change The new PKGBUILD that I'll be pushing shortly uses a different version scheme. Instead of only the SVN revision number, it also includes the LLVM version number itself. For example, instead of version 241875-1, the new package will have version 3.8.0svn_r244189-1. This is meant to not only help users easier determine what LLVM version they are using, but also to be as close to the output of `llvm-config --version` as possible. However, because of how Pacman treats version numbers, it and likely all AUR helpers that you may be using (e.g. Yaourt) will recognize the new version as a _downgrade_. YOU WILL NEED TO ACCEPT OR FORCE THIS "DOWNGRADE". This will happen only once; all subsequent upgrades should proceed as expected. Sorry for this inconvenience. Technically, it would've been possible to avoid the issue altogether by using the "epoch" variable, but I feel the case doesn't call for such radical measures.

kerberizer commented on 2015-08-05 19:43 (UTC)

Fixing this package actually turned out to be not that difficult now that most work had been done in llvm-svn. It's also on GitHub... https://github.com/kerberizer/lib32-llvm-svn Again, all comments and suggestions will be much appreciated.

kerberizer commented on 2015-08-05 14:39 (UTC)

Guys, since @Krejzi has stepped down as a maintainer (once again many thanks for all his work on this!), I might try to take his place. However, if there are more knowledgeable and experienced in LLVM and AUR people around, who would be willing to step in, that will certainly be a better choice. If you feel like it, please don't hesitate to raise your hand. ;) If no one else volunteers, I'll take over, at least temporarily, this and the llvm-svn package, though I won't be able to fix this one immediately.

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