Package Details: libc++abi 7.0.0-1

Git Clone URL: https://aur.archlinux.org/libc++.git (read-only)
Package Base: libc++
Description: Low level support for the LLVM C++ standard library.
Upstream URL: https://libcxx.llvm.org/
Licenses: MIT, custom:University of Illinois/NCSA Open Source License
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 203
Popularity: 11.125500
First Submitted: 2017-02-04 16:09
Last Updated: 2018-10-03 16:39

Pinned Comments

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 »

arality commented on 2018-12-11 22:57

@astize You need to import the keys from the PKGBUILD https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver

astize commented on 2018-12-08 01:41

Getting the following error when running makepkg:

==> Verifying source file signatures with gpg...

llvm-7.0.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)

libcxx-7.0.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)

libcxxabi-7.0.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)

DarkXylese commented on 2018-12-03 08:10

I've had so much trouble with this package, that I was forced to stay on the 6.* version. But in my case it was a simple fix of deleting gpg.conf from .gnupg in my home directory. Hopefully this helps someone.

kwyjib0 commented on 2018-10-15 04:06

Thanks for uploading.

tzcrawford commented on 2018-10-10 22:50

WoefulDerelict: https://wiki.archlinux.org/index.php/Clang#Build_packages_with_Clang

WoefulDerelict commented on 2018-10-09 18:08

tzcrawford: The output you've submitted leads me to believe your problem is quite different from the issue Asgaroth encountered. Asgaroth encountered issues during check() as the test suite isn't compatible with mismatched versions of clang. Your issue is appearing much earlier in the process while cmake is attempting to configure things in build(). The output you've submitted leads me to believe that you have altered/customised the config files for the Arch Build System, adding an option which clang does not support. While I am able to reproduce the issues users have experienced when attempting to run the test suite against clang 6.0.1 and clang 8.0.0 I can not reproduce your issue.

Asgaroth: If you regularly work with the llvm-svn tools you can avoid modifying your host system by building the package in a clean chroot. The scripts in the devtools package greatly simplify the process, constructing an up to date chroot for you before building the package inside it. You can of course do this manually as well. See the pinned posts for a link to more information and instructions for both methods.

lesebas: Calling makepkg with -si is a simple and acceptable option. It does; however, install all three packages the PKGBUILD makes which you may not need. When installing libc++ with pacman you can include libc++abi in the same line and avoid installing libc++experimental as most users likely don't need that package. This looks something like the following with libc++ 7.0.0:

# pacman -U libc++abi-7.0.0-1-x86_64.pkg.tar.xz libc++-7.0.0-1-x86_64.pkg.tar.xz

lesebas commented on 2018-10-09 11:40

Hi... OK I was trying to build and install the package with makepkg + pacaman -U. A simple makepkg -si worked perfectly!

Asgaroth commented on 2018-10-09 08:11

WoefulDerelict: I downgraded llvm-svn and clang-8 to llvm-7 and clang-7 and the build went through successfully, thanks for the point in the right direction.

tzcrawford commented on 2018-10-08 23:58

I am having a similar problem to Asgaroth, I think, but I am using clang-7.0.0. I am failing during build.

/usr/bin/clang   -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -g -fvar-tracking-assignments -fdebug-prefix-map=/Apps/libc++/libc++/src=/usr/src/debug -o CMakeFiles/cmTC_d4883.dir/testCCompiler.c.o   -c testCCompiler.c
clang-7: error: unknown argument: '-fvar-tracking-assignments'
ninja: build stopped: subcommand failed.




CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:50 (project)


-- Configuring incomplete, errors occurred!
See also "/Apps/libc++/libc++/src/build/CMakeFiles/CMakeOutput.log".
See also "/Apps/libc++/libc++/src/build/CMakeFiles/CMakeError.log".
==> ERROR: A failure occurred in build().

WoefulDerelict commented on 2018-10-08 19:15

Asgaroth: The output you've submitted states that you're attempting to build and test libc++ 7.0.0 against clang 8.0.0. The libc++ 7.0.0 test suite is likely failing as clang 8.0.0 behaves differently than clang 7.0.0 producing an unexpected result. The LLVM ecosystem is tightly integrated. Testing against mismatched components will frequently result in errors. 7.0.0 is the current version of clang available in [Extra]. You could resolve the issue by building libc++ 7.0.0 against the current/matching release of clang in a clean chroot.

lesebas: libc++ is not a make dependency of libc++abi. This is a split package. The PKGBUILD constructs three packages: libc++, libc++abi and libc++experimental.