Package Details: clang-analyzer-svn 5.0.0svn_r298556-1

Git Clone URL: (read-only)
Package Base: llvm-svn
Description: Source code analysis tool for Clang, supporting C, C++, and Objective-C
Upstream URL:
Keywords: clang llvm
Licenses: custom:University of Illinois
Groups: llvm-toolchain-svn
Conflicts: clang-analyzer
Provides: clang-analyzer
Replaces: clang-analyzer
Submitter: None
Maintainer: kerberizer
Last Packager: kerberizer
Votes: 73
Popularity: 0.748457
First Submitted: 2007-08-02 07:15
Last Updated: 2017-03-22 23:54

Pinned Comments

kerberizer commented on 2016-08-11 00:39


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

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

Latest Comments

kerberizer commented on 2017-03-22 23:57

[NOTICE] Bug 31610 has been fixed by r298551, so I've reenabled the LLVM regression tests.

kerberizer commented on 2017-03-18 08:30

@lahwaacz, thank again for the helpful information and feedback.

I've been thinking about different solutions: let's imagine that we keep the current packages as they are, but also introduce a new one, say "llvm-libs-lite-svn", which will include _only_ the versioned libs from the current "llvm-libs-svn" and thus won't conflict with llvm-libs from extra. In that way, the people who need the very latest libLLVM (possibly also libLTO) will be able to install them, while at the same time keeping everything else LLVM-related "stock"--that is, from the official repositories.

Obviously, those who also need the unversioned libs (mainly, I guess) will have to use the "ordinary" llvm-libs-svn and therefore won't be able to install llvm-libs from extra. But for them, we could still provide "llvm-libs-compat-svn", which would include only the versioned libs from the "stock" llvm-libs, so it's kind of the opposite to llvm-libs-lite-svn.

Here's a brief summary, in case the above sounded confusing:
* llvm-libs: the "stock" package from extra, containing both the versioned and unversioned libraries of the latest LLVM release (currently 3.9);
* llvm-libs-svn: our package, as we have it now, containing both the versioned and unversioned libraries of the LLVM svn trunk (currently 5.0.0svn);
* llvm-libs-lite-svn: contains _only_ the versioned libraries from 5.0.0svn;
* llvm-libs-compat-svn: contains _only_ the versioned libraries from 3.9.

So, the users have the following choices:
* use only llvm-libs: will have access only to the 3.9 libs;
* use only llvm-libs-svn: will have access only to the 5.0.0svn libs;
* use llvm-libs + llvm-libs-lite-svn: will have access to all 3.9 libs + the versioned 5.0.0svn ones;
* use llvm-libs-svn + llvm-libs-compat-svn: will have access to all 5.0.0svn libs + the versioned 3.9 ones.

This doesn't cover all possible use cases, but I hope that it'll be able to cover most. What do you think, lahwaacz? And everyone else, of course. Feel free to comment here or in

lahwaacz commented on 2017-03-17 18:12

@kerberizer Yes, I have extra/mesa installed and the problem I recently encountered was asymptote failing to run, because it links to which links to (explicitly this version). So pretty much the same issue as #13 you mentioned: something links to an explicit version of libLLVM, but the package depends just on llvm-libs.

I'm not really sure how the dynamic linking works exactly, but the libraries that the linker sees may not be the same libraries the dynamic loader sees. Especially the lookup order is important in case of multiple unversioned libraries living in different directories. See e.g. FS#51611 for a problem with vtk6 and vtk7. But since libLLVM is properly versioned, I don't see many problems here: you just need to configure the compiler (include paths + library versions, e.g. -lLLVM-5.0svn). If the libs coexist and the user wants to compile against the svn version, he will have to configure the include paths anyway so I don't see a problem with configuring also the version. But yes, the other unversioned libs are problematic...


kerberizer commented on 2017-03-17 16:59

@lahwaacz, thanks for raising this good point again. I've been thinking about it for some time, including in as mentioned earlier. The problem is that it seems difficult to accommodate for all the different—and sometimes conflicting—needs. I'll need to do some testing with various scenarios to see what might be the optimal approach. I'm particularly worried about use cases where the "generic" and symlinks are from the extra/llvm-libs package, but the user wants to compile against e.g. (some compilers allow a specific library+version name, but others don't). Yet, even more complex is the gold plugin. Probably a proper solution for it would be to put it in a subdirectory, not unlike what the Debian packages do with the different LLVM versions, but, again, that's something that I probably need to test first.

Just to make sure I understood you problem correctly: you use mesa from extra (i.e. not mesa-git) and it has problems with llvm-libs-svn?

lahwaacz commented on 2017-03-17 09:48

Would it be possible to have the llvm-svn packages installed alongside the official llvm packages? This would avoid the conflict between llvm-libs-svn and llvm-libs and the breakage of anything that links to llvm-libs but does not depend on the explicit version it links to (e.g. mesa).
I'm not using llvm-svn due to mesa-git but due to features not present in 3.9 (notably better CUDA support in clang 4.0) so I would welcome if I could stay with the stable versions of those packages without any breakage (which I even noticed only after several months anyway). This will be probably much smaller problem when 4.0 is pushed to the official repos, but the same problem might come again in the future...

kerberizer commented on 2017-03-04 04:44

[OPINIONS NEEDED] For those who use the binary repo, I'd be happy to hear your opinion on these two issues:


If you don't have an account on GitHub (and don't want to register one), feel free to also comment here.

kerberizer commented on 2017-03-04 04:38

[NOTICE] A few changes:
* lld ( is now included in the llvm-svn package, thanks to hesiod@GitHub. If you think it's better for it to be in a separate package, please let me know.
* The LLVM unit tests that have been failing since around early to mid-January have been disabled (I guess those of you who build the package on your own had already done that long time ago). This is now a properly recognized and 4.0.0 release blocker bug. More info/comments: and If you think you can help, don't hesitate to do it.
* A somewhat cosmetic change: the packages should now include all the licenses that are included in the source distribution (well, technically not all, since some are referenced only as being included in specific header and other similar files and including them would be an overkill, I guess).

kerberizer commented on 2017-02-27 20:00

@WoefulDerelict, thank you very much for the notice! I'm actually fine with either solution, but one obvious benefit if libc++/abi becomes part of this PKGBUILD is that I'll be able to also provide binary packages from the llvm-svn repo that I maintain.

Like it usually happens, the devil is in the details. As discussed on, one important issue is whether to use GCC or Clang -- and which Clang too -- for building the library, which gets further complicated by the nature of the split packages. My experiments so far have shown that each compiler leads to different libcxx unit tests failing: 4 tests were failing with GCC vs 1 with Clang from extra. The second problem is exactly those failing tests. I indeed tend to be a perfectionist, but a failing unit test is usually not a good indication, perfectionist or not. I'd really like to solve or at least have a clear path to solving these issues before merging libc++/abi, and any help with this will be really appreciated.

And speaking about help, I'll also be very grateful if people knowledgeable with YAML take a look at, resp. I've already bisected the problem (at least on Arch), but more eyes and testing are needed to understand why this is (likely) failing only on certain distributions/systems.

Edit: Wrongly referenced the issue rather than the pull request.

WoefulDerelict commented on 2017-02-27 19:02

brunocodutra stopped by libc++ [] asking how I felt about maintaining an -svn variant of the split package. The user also referenced a discussion here:

One is referencing this here to document the forthcoming work to include libc++-svn/libc++abi-svn in this split PKGBUILD transparently in the AUR in order to help prevent the appearance of PKGBUILD(s) that would block inclusion.

streetwalrus commented on 2017-02-17 12:38

Yeah, I'm using this package for mesa-git as well, but I also use Dolphin. Thanks a lot!

All comments