Package Base Details: libc++

Git Clone URL: (read-only, click to copy)
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 248
Popularity: 2.27
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. []

Latest Comments

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

WoefulDerelict commented on 2018-07-21 11:28

SupKurtJ: As has already been mentioned earlier, AUR helpers are not supported. yaourt conducts the build in /tmp which is volatile and resides entirely in memory by default []

The libc++ test suite has some memory heavy functions which users have already noted can cause issues when using yaourt on systems with limited memory. This is not an issue when building with makepkg. You can pass --nocheck to makepkg in order to skip the test suite as noted in the pinned post.

WoefulDerelict commented on 2018-07-20 17:12

SupKurtJ: It is difficult to to accurately diagnose a problem without the program's output. There are a number of factors that can cause key retrieval to fail. The most common culprit is strict firewalls that block the default HKP/HKPS port. You could try specifying a different port and see if that resolves the issue. The default HTTP and HTTPS ports tend to be the most viable options. The following is an example using HKPS and the http over TLS/SSL port 443.

gpg --keyserver hkps:// --recv-keys 474E22316ABF4785A88C6E8EA2C794A986419D8A

Here is an example using the standard hypertext transfer protocol port 80.

gpg --keyserver hkps:// --recv-keys 474E22316ABF4785A88C6E8EA2C794A986419D8A

You can get more detailed output from gpg using the -vvv and --debug-all options. If neither of those work you can skip the PGP signature check by passing --skippgpcheck to makepkg as noted in the pinned post above.

Joan31 commented on 2018-07-20 13:19

Hello, gpg --recv-keys 474E22316ABF4785A88C6E8EA2C794A986419D8A doesn't work. I can't install libc++. What's wrong ? Thank you

Kunda commented on 2018-07-12 14:21

I got the relevant keys from looking the PKGBUILD 'validpgpkeys' array ( and ran gpg --recv-keys <the-alphanumeric-gpg-key> but I noticed i needed to add all the keys in the array + i needed to run the commands a few times because it failed connecting to the gpg servers

WoefulDerelict commented on 2018-07-12 02:55

DescartesHorse: One can't fault you for being careful and inspecting things with due diligence.

WoefulDerelict commented on 2018-07-12 02:06

pepper_chico: I build and test this package on an aging Nehalem processor from 2010. The tests use the maximum number of threads available on the host system by design. It takes less than 20 minutes for the build and tests to complete on my eight year old system.

Your experience is not representative of the Arch Linux package ecosystem as a whole. Plenty of packages take far longer and consume more resources to build than this one. check() functions are present in many Arch PKGBUILDs and are a recommended practice. []

The test suite has never been broken. The majority of users who've complained here in the comments about issues with the tests were using AUR helpers and were able to successfully complete the build and tests with makepkg. The other failures resulted from users failing to properly follow the Arch Linux Install Guide [] and install a POSIX compliant locale.

DescartesHorse commented on 2018-07-12 01:31

@WoefulDerelict: Thanks; I'll look into that :) Whilst I recognise it's an extremely low chance of being the result of a compromise, I do like to practice good security and be on the safe side! Much appreciated

WoefulDerelict commented on 2018-07-12 01:12

DescartesHorse: I suspect the new email address was the reason behind the key change. You can certainly check with Tom via email and ask him about signing the new key with the old one or ask the community in #LLVM on OFTC []. While it is entirely possible that the LLVM Project's web presence was compromised and a fraudulent release and keys were posted there, I suspect this is a highly unlikely explanation for the new key not being signed by the old. The same key is used for the official/binary LLVM and Clang packages in [Extra].

pepper_chico commented on 2018-07-12 01:06

WoefulDerelict: Great it isn't broken now, but as can be checked from comment history, it has not been uncommon, and besides that, personally I've gone through it breaking on tests before, so the time/resource spent until it breaks on one of its million tests is simply lost. I'm on a 7700K desktop, the tests take all threads of the CPU, and it still takes a couple of minutes, it's the sole package in my system that does this.

DescartesHorse commented on 2018-07-12 00:53

So I noticed in the latest commit that Tom's PGP signing key has changed to the redhat address - however, the previous signing key hasn't signed the redhat address (nor have any other keys for that matter). Have we any way to prove this is legitimate? Can we get Tom to sign the new Redhat key with the old key?