Package Base Details: libc++

Git Clone URL: (read-only, click to copy)
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 248
Popularity: 2.53
First Submitted: 2017-02-04 16:09
Last Updated: 2020-05-07 18:42

Pinned Comments

eschwartz commented on 2019-01-21 03:57

PSA: Due to repeated abuse, this package is now a ZERO-TOLERANCE ZONE for rules violations.

Hi people, sorry for the interruption if you're the majority of users just innocently doing your thing, if so, feel free to just move on. For the rest of you, this is your final reminder regarding the following points, which shall now be grounds for having your account suspended:

  • Thou shalt not complain about makepkg's validpgpkeys feature.

  • Thou shalt not complain about makepkg's check() feature.

  • Thou shalt not under any circumstances ever insult the maintainer for implementing said features.

This package is doing the correct thing, and there has been a great deal of pointless moaning and whining about it despite the pinned comments explaining why these complaints are not only null and void, but also ridiculous because they can already be disabled. This nagging stops now.

The banhammer is ready and waiting in case you still want to ignore all this on top of the Trusted User warning(s).

Alad commented on 2018-08-22 12:58

Holy shit guys. What's unclear about "AUR helpers are not supported"? Stop this incessant spam and learn how to use makepkg.

Any comments on AUR helper issues will be deleted from now on. Repeat offenders will have their accounts suspended.

WoefulDerelict commented on 2018-07-21 11:45

If you experience issues when using an AUR helper please try again using makepkg. AUR helpers are not supported here. The AUR article in the ArchWiki documents the prerequisites and supported process.

The test suite contains tests for multiple locales including: en_US.UTF-8, fr_FR.UTF-8, ru_RU.UTF-8, zh_CN.UTF-8, fr_CA.ISO8859-1 and cs_CZ.ISO8859-2. If a locale isn't present on the system the related tests will be marked as unsupported and skipped.

If you encounter issues when building with makepkg please attempt to build this in a clean chroot using using the appropriate devtools script. The Arch Linux DeveloperWiki has an article focused around building packages in a clean chroot which contains information on the devtools scripts and explains the process of building in a clean chroot:

There is an active community of users on IRC along with a vibrant Discord server and Forums should you require assistance.

Picking a fight with one of the Trusted Users is a terrible idea.

WoefulDerelict commented on 2017-02-05 03:42

This PKGBUILD verifies the authenticity of the source via PGP signatures which are not part of the Arch Linux keyring. In order to complete the process it is necessary to import the key(s) from the ‘validpgpkeys’ array into the user’s keyring before calling makepkg. There is a helpful article explaining this process by one of Arch Linux's developers located here:

Instructions on importing keys from a keyserver and how to automate the retrieval process can be found in the Arch Linux wiki here: This article also contains helpful information describing the installation of GnuPG, its configuration and usage.

Execute the following to import keys using gpg:

gpg --recv-keys <KEYID - See 'validpgpkeys' array in PKGBUILD>

The PGP signature check can be skipped by passing --skippgpcheck to makepkg.

The libc++ test suite can be skipped by passing --nocheck to makepkg.

Consult the makepkg manual page for a full list of options. []

doskoi commented on 2017-02-17 18:03

@giorgosioak You don't have to trust it if the key is in the validpgpkeys array.

giorgosioak commented on 2017-02-17 15:37

If gpg signatures can't be verified, add the key as regular user by gpg:
gpg --recv-keys KEYID
and trust it:
gpg --edit-key KEYID
When you see a gpg prompt, run command: trust
and choose full or ultimate.
Re-run build procedure. And done. Hope it helps.

brunocodutra commented on 2017-02-17 15:37

@WoefulDerelict Thanks for the heads up, in fact I was aware of those guidelines and I followed them to the best of my knowledge.
I don't know about the vast majority of users, but I believe anyone interested on llvm-svn, would also be interested on libc++-svn, which is not provided by the former yet:

For the record, these are the main changes I made to build from trunk


pkgver() {
cd "${srcdir}/llvm"

# shamelessly stolen from llvm-svn PKGBUILD
echo $(awk -F 'MAJOR |MINOR |PATCH |SUFFIX |)' \
'BEGIN { ORS="." ; i=0 } \
/set\(LLVM_VERSION_/ { print $2 ; i++ ; if (i==2) ORS="" } \
END { print "\n" }' \
CMakeLists.txt)_r$(svnversion | tr -d [A-z])

prepare() {
[[ -d llvm/projects/libcxx ]] || ln -s ${srcdir}/libcxx llvm/projects/
[[ -d llvm/projects/libcxxabi ]] || ln -s ${srcdir}/libcxxabi llvm/projects/

sed -i 's/CREDITS.TXT/CREDITS/' llvm/projects/libcxx/LICENSE.TXT
sed -i 's/CREDITS.TXT/CREDITS/' llvm/projects/libcxxabi/LICENSE.TXT
[[ -d build ]] || mkdir build

WoefulDerelict commented on 2017-02-17 12:10

brunocodutra: There are additional guidelines that apply to VCS packages (; however, much of the content between a realease and VCS package of the same software does remain the same unless upstream makes drastic changes. I didn't anticipate interest in tracking development and building from repository snapshots given this was static at 3.8.0 in [Community] for quite some time. If there was enough interest it would be simple to construct and maintain a proper VCS package alongside this one. I suspect that the vast majority of users will prefer building the release instead of a snapshot of the source code repository to avoid tangling with bleeding edge issues and failed builds.

Elrondo46: Please read Arch Linux developer Allan McRae's blog post about makepkg and verifying signed sources (the first URL in the pinned comment at the top) along with the standard documentation on packaging as you obviously have no idea what is going on.

Elrondo46 commented on 2017-02-17 09:40

And if you can no more using gpg's user fucking keys. that's useless

brunocodutra commented on 2017-02-17 09:33

Though I have virtually null experience with writing PKGBUILD recipes, I've easily forked this into libc++-svn by reusing the build steps but fetching sources from the tip of the trunk instead.

Would it be of your interest to maintain it? If needed I could provide you with what I got so far, otherwise I'd be willing to maintain it myself as well.

WoefulDerelict commented on 2017-02-13 03:30

rubenvb: It is not necessary to build libc++ or libc++abi in the LLVM tree; however, it is the recommended method for building the software described upstream. Building the libraries out of the LLVM tree results in an unnecessarily noisier build. While testing the individual PKGBUILDs for libc++ and libc++abi from [Community] in clean environments during the process of updating and publishing a PKGBUILD here one found the dependencies expressed in the PKGBUILDs accurate. It isn't possible to build either library without a compiler and the required headers.

Building the software in tree, in a split pakcage, with minimal warnings was chosen as the final incarnation after feedback from users here and a discussion with developers from the LLVM community. This is not the only way to build or package the software and you are free to use whatever recipie you choose on your local system.

rubenvb commented on 2017-02-12 21:47

Why is it necessary to build this as part of LLVM? Before this AUR package, I kept a local PKGBUILD for libc++ 3.9 (I needed std::filesystem) and I could build it from just libc++ sources alone.

What does building it inside an LLVM tree give us?

WoefulDerelict commented on 2017-02-11 03:25

c-korn: I'm not sure why you're having trouble fetching the keys; however, I've placed URLs to the keys in plain text as comments inside the PKGBUILD. Hans Wennborg's key is hosted at and there are links to it on the download page beneath releases signed by his key. Tom Stellard's key can be directly downloaded from a public keyserver like

Good luck.

c-korn commented on 2017-02-10 21:26

Somehow my GnuPG refuses to download the signatures. Where can I download them in plaintext? Did not find any of those here: