Package Details: libc++ 9.0.0-1

Git Clone URL: https://aur.archlinux.org/libc++.git (read-only)
Package Base: libc++
Description: LLVM C++ standard library.
Upstream URL: https://libcxx.llvm.org/
Licenses: custom:Apache 2.0 with LLVM Exception
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 236
Popularity: 3.155941
First Submitted: 2017-02-04 16:09
Last Updated: 2019-10-11 20:38

Pinned Comments

eschwartz commented on 2019-01-21 03:57

Hi people, this is your regular reminder to SHUT UP about validpgpkeys checks and complaints about the fact that test suites exist.

This package is doing the correct thing, and there has been a great deal of pointless moaning and whining about it, but there is also multiple pinned comments explaining why every one of those complaints is not only null and void, but retroactively ridiculous.

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

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.

https://wiki.archlinux.org/index.php/Makepkg https://wiki.archlinux.org/index.php/Arch_User_Repository

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. https://wiki.archlinux.org/index.php/Arch_User_Repository

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: https://wiki.archlinux.org/index.php/DeveloperWiki: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: http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/

Instructions on importing keys from a keyserver and how to automate the retrieval process can be found in the Arch Linux wiki here: https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver 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. [https://www.archlinux.org/pacman/makepkg.8.html]

Latest Comments

1 2 3 4 5 6 ... Next › Last »

actionless commented on 2019-10-11 18:21

there is a SRCINFO/PKGBUILD mismatch:

https://aur.archlinux.org/cgit/aur.git/commit/?h=libc%2b%2b&id=bdc69e89ffa6

particularly see llvm package in makedepends

WoefulDerelict commented on 2019-07-16 15:50

Teemperor: Thanks for spotting an issue and doing a little legwork. I am able to reproduce the behaviour and it was the result of a mistake in packaging. It crept in during the 6.0.0 update when the PKGBUILD migrated from make to ninja. This has been masked as the majority of consumers using libc++ at the time were only interested in compatibility with the binaries distributed for the Electron based Discord chat client.

The fix was far simpler than any of your suggestions and came from observing how upstream told ninja to behave when the experimental components were explicitly disabled. Even when the experimental features are explicitly disabled ninja includes their headers when executing install-libcxx. The module.modulemap file is identical to the one installed when the experimental features are enabled. Including the experimental headers in the libc++ package should respect the behaviour upstream intends while still allowing the experimental features to be packaged separately.

Teemperor commented on 2019-06-01 14:06

I think the separation of libc++ and libc++experimental is incorrect as it breaks the module compilation with libc++. This can be reproduced with the following command when libc++ is installed but libc++experimental is not:

echo "#include <vector>" | clang++ -fsyntax-only -fmodules -stdlib="libc++" -Rmodule-build -xc++ -

The reason for this is that the modulemap file of libc++ refers to both standard and experimental headers and wants to put all of them into the 'std' module.

From what I can see there are four possible fixes:

  1. libc++experimental and libc++ become one package.
  2. We patch the modulemap file in the PKGBUILD and remove the experimental headers.
  3. The modulemap file becomes its own package that has to be installed.
  4. The modulemap file will only installed with libc++experimental.

WoefulDerelict commented on 2019-01-22 05:37

anatolik: In this case you are preaching to the choir. I've already been made aware of the change in Android Tools and it does stand to reason that once this change hits release and in doing so creates a package in [Community] that depends on libc++ users will see it back in the binary repos. I suspect it will be an altered form as the maintainers will see little value in packaging the experimental bits and the other static libs to go with them.

As libc++ would always need the associated abi it may very well be simplified into a single package which included both and excluded the extraneous experimental stuff.

anatolik commented on 2019-01-22 05:26

Android Tools from master branch uses LLVM's libc++ and does not work with GCC's version.

WoefulDerelict commented on 2019-01-22 05:17

anatolik: While I will not argue the usefulness of libc++, at present no software distributed in the Arch Linux binary repositories depends on it which is why it was dropped from [Community] in early 2017. It is possible this could change; however, for the immediate future users of libc++ will have to build it.

anatolik commented on 2019-01-21 17:34

This package is important and has so many votes. It should really belong to [community] repo.

eschwartz commented on 2019-01-21 03:57

Hi people, this is your regular reminder to SHUT UP about validpgpkeys checks and complaints about the fact that test suites exist.

This package is doing the correct thing, and there has been a great deal of pointless moaning and whining about it, but there is also multiple pinned comments explaining why every one of those complaints is not only null and void, but retroactively ridiculous.

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

WoefulDerelict commented on 2019-01-02 19:32

Greg89: One can not reproduce this issue. At present the integrity checks pass. Clean the build directory and try again as it is likely that one of your downloads didn't complete successfully and the archive is incomplete.

Greg89 commented on 2019-01-02 19:03

Hello, it seems that the sha key is no longer valid. Thanks for doing some updating;) cordially