Package Base Details: libc++

Git Clone URL: (read-only, click to copy)
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 250
Popularity: 1.54
First Submitted: 2017-02-04 16:09
Last Updated: 2020-11-20 22:58

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. []

WoefulDerelict commented on 2017-08-09 03:40

squidman: I am unable to reproduce this issue in testing. I am perfectly capable of executing gpg --recv-keys on they key for the current release [Tom Stellard <> (.1 releases),, 11E521D646982372EB577A1F8F0871F202119294] using the same fingerprint [8F0871F202119294]. I do not; however, make a habit of using a different keyserver than the default shipped with GPG [hkp://] and have yet to encounter an issue where I was unable to receive a key I needed to verify the sources for a package.

OrangeInk commented on 2017-08-01 13:39

I'm trying to build a static version of libc++ (libc++.a) alongside with

I added -DLIBCXX_ENABLE_STATIC=On flag to "cmake" call and cxx_static flag to "make" call in "build()" function. My PKGBUILD is here:

It's built properly and I can see libc++.a in src/build/lib/ folder.

make DESTDIR="${pkgdir}" install-libcxx
command runs (package_libc++() function) I see this output:
Scanning dependencies of target install-cxx
-- Install configuration: "Release"
-- Installing: /home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/
-- Installing: /home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/
-- Installing: /home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/
-- Set runtime path of "/home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/" to ""
-- Installing: /home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/libc++.a
-- Installing: /home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/libc++experimental.a

full output here:

So as you can see libc++.a is copying.
But after all I can't find this file in /home/user/.cache/pacaur/libc++/pkg/libc++/usr/lib/ or libc++-4.0.1-1-x86_64.pkg.tar.xz either, it just disappeared.

But if run
cd src/build/
make DESTDIR=pkg/libc++ install-libcxx
in terminal it successfully appears in the folder.

Any ideas?

WoefulDerelict commented on 2017-07-10 15:33

Plexcon: Please see the pinned post concerning source signature verification.

Plexcon commented on 2017-07-10 08:21

==> ERROR: ¡No se ha podido verificar alguna de las firmas PGP!

WoefulDerelict commented on 2017-06-28 02:11

foutrelis: If one parses the information presented properly, upstream has already addressed the issue. Additional overhead in the PKGBUILD to mask future regression seems excessive.

It appears the appropriate solution is for users to update to the current release.

foutrelis commented on 2017-06-28 01:52

FYI: — To ensure this doesn't break in the future you might consider explicitly enabling LIBCXX_ENABLE_ABI_LINKER_SCRIPT.

Anonymous comment on 2017-04-30 09:57

Just adding this to say that yes the keys are the valid LLVM sign keys.
1. and

Or just use `gpg --recv-keys 345AD05D` to import it.

WoefulDerelict commented on 2017-04-04 15:00

pointhi: Quite. I am totally asleep at the wheel on this update. Fixing it presently and will have the revised PKGBUILD live soon. Apologies for the derp, it is like I forgot how to build this. I blame lib32-qt4 >.>;

pointhi commented on 2017-04-04 08:53

It seems you also need to include __cxxabi_config.h:

/usr/bin/../include/c++/v1/cxxabi.h:21:10: fatal error: '__cxxabi_config.h' file not found

WoefulDerelict commented on 2017-04-03 15:19

sharivegas: The keys in the PKGBUILD are labeled as to which release versions are signed with which key. If one plans to track, build and use this package at each release fetching both keys would be prudent.

pointhi: Changes in make install for 4.0 resulted in cxxabi.h not being included in the finished package. I've included it as part of libc++abi in the latest release of this PKGBUILD. Thanks for spotting and reporting the issue.