Package Base Details: libc++

Git Clone URL: https://aur.archlinux.org/libc++.git (read-only)
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 237
Popularity: 3.933488
First Submitted: 2017-02-04 16:09
Last Updated: 2019-07-23 23:00

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

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

zakimano commented on 2018-03-23 15:11

TL;DR (Mostly for newcomers): Yaourt should be avoided, and if you cannot complete tests on this, turn them off for now, as seen in the comments below.

WoefulDerelict: Thanks for the effort, and pointing out that yaourt should be avoided - it really should. I re-ran the whole build process with just makepkg, this time the tests could actually complete, however I still experienced a higher (~ 2GiB) peak memory usage than what you did, investigating the issue now...

Getting the llvm / libc++ / libc++abi from the provider - http://libcxx.llvm.org/ - and following their guide to build and test libc++, I was able to reduce the issue to the std/input.output/stream.buffers/ group of tests. For further investigation I had to use a tool (https://github.com/pshved/timeout) to kill the process as soon as it crosses the 2 GiB line - and with that I could pinpoint exactly; the culprit is the:

test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp

Exact command, according to the build & test guide @ libcxx.llvm.org: lit -sv test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp I ran it like this: timeout -m 2100000 lit -sv test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp

Which, as it's name states, is a test for strings about 2 GiB in size.

Assuming that the timeout tool I used knows what it's doing (it seems to be) this test, even when I set the memory limit to 3GiB, breaks that limit (gets shut down by the tool). This behavior might be just for a moment though - but it was enough to make my weak-ass laptop crash and burn when I tried to build the package with yaourt.

[edit] Valgrind information is irrelevant, as the timeout tool kills the process before it could complete. It seems that I cannot run this test on my own machine with diagnostics tools enabled. [/edit]

As for the exact cause of this issue, I cannot provide more meaningful information without help from someone who understands C++ / Unittests better than me.

Ps.: Sorry for the late (and long) reply, I didn't want to post before I knew and understood as best as I can what was going on.

[edit 2]

Update: If I set the timeout script to a threshold of about 5GiB, that way the whole test can run, and complete. The output it gives looks like this: FINISHED CPU 6.83 MEM 333676 MAXMEM 4657000 STALE 6 MAXMEM_RSS 3417208 Where MAXMEM is the maximum amount of memory used - clearly a tad higher than the 2 GiB I was expecting. But I think this is probably for just a few miliseconds.

WoefulDerelict commented on 2018-03-22 01:25

zakimano: Thanks for the update. If you have a moment to retry the build using makepkg and see if it suffers from the same issue I would appreciate it. My own test system has an abundance of RAM and is based on ZFS so it may mask a spike in memory usage during the tests. I'll fire up a VM when I get a free moment and see if I can't get a clearer picture of test suite's memory usage.

Update: Having completed the build and test suite on a memory restricted virtual machine one can confirm the process neither populates the entirety of a system's RAM and swap space nor does it cause the system to become unresponsive. The VM was configured with 4 cores and 2 GB of RAM and swap. The process ran for about 25 minutes with an average memory footprint of 400 MB. The highest spike I observed was 900 MB. While this might pose an issue on a Raspberry Pi I would wager even those would be able to complete the test suite with a modest amount of swap space.

zakimano commented on 2018-03-21 23:30

Ye, sorry about that.

I too realized the pointlessness of that comment, gonna leave it as is, since I was stupid enough to write it. But I re-tried, just to see if this, from yaourt-manpage: --tmp <dir> Use <dir> as temporary folder. default to /tmp Would change anything. And even with that set, (yaourt -Sy libc++abi --tmp ~/yaourtbuild/) I get the same behaviour, it just fills up the ram when performing tests.

The main takeaway here is that I'll stay far away from yaourt from now on, and continue to look into this issue.

WoefulDerelict commented on 2018-03-21 20:55

zakimano: Your problem stems not from the tests but from yaourt and its ridiculous behaviour. yaourt conducts the entire build in /tmp which is volatile and resides entirely in memory by default [https://wiki.archlinux.org/index.php/tmpfs]. This behaviour is responsible for the issue you encountered and not the libc++ test suite. It would be wise to consult the documentation before bothering maintainers with inane comments.

zakimano commented on 2018-03-21 20:20

Thanks for the quick replies.

Running yaourt -Sy libc++abi --m-arg --nocheck did the trick.

As for the necessity of the tests, I agree, it's a good thing to test the packages - but at the same time, I can't agree to tests that are unsafe.

By 'unsafe' I mean that they can very potentially cause a system to hard-freeze, requiring manual restart, or similar. In my case, I have a laptop with an i5-5200U and 4 GiB of RAM. So it has rather common specs, which makes it a good example of what kind of machines others might use out there. And the tests on this machine filled up all of the avaiable RAM, then started to fill up the SWAP. I could follow it until it hit the 2 GiB mark into the SWAP - I don't know how far it got, but I suspect a good 5-6 GiBs of memory is required to run the tests, at the very least. Obviously I had to manually restart the machine, as it was completely frozen. This also means that these tests could easily break stuff when run in a production environment, for example.

Now that is something that shouldn't be on a stable channel package. Either use / write tests that detect system specs, and keep themselves on a scale that fits the current system, or simply use tests that operate on a scale that no machine today would have problems running them.

WoefulDerelict commented on 2018-03-21 16:50

zakimano: To skip the check() function simply pass the --nocheck option to makepkg. https://www.archlinux.org/pacman/makepkg.8.html

Griever: check() functions are present in many Arch PKGBUILDS and are a recommended practice [https://wiki.archlinux.org/index.php/creating_packages#check.28.29]. Users who don't want to deal with the overhead can disable the tests easily just as one can skip the process of verifying the source via PGP signatures.

On an i7-870 from the later half of 2009 the process of building and testing libc++ takes just over 15 minutes.

zakimano commented on 2018-03-21 11:47

Hi there!

How can I disable tests for this? When trying to install, it runs about ~5400 tests, if I recall correctly, and while it's slightly annoying to have your CPU maxed out for 10 minutes straight, after that it starts to fill up my RAM like crazy, which then continues with my SWAP, and that obviously didn't end well.

Thanks in advance

WoefulDerelict commented on 2018-03-21 05:57

Ampera, menfie: One is expected to have installed the base-devel group [https://www.archlinux.org/groups/x86_64/base-devel/] BEFORE attempting to build packages. This group includes fakeroot, gcc and make along with other tools necessary to successfully build packages on an Arch Linux system. https://wiki.archlinux.org/index.php/creating_packages#Preparation

Morganamilo commented on 2018-03-16 23:56

The PGP keys appear to be missing from the .SRCINFO. manually running makepkg --printsrcinfo generates a srcinfo with PGP keys included.

Ampera commented on 2018-03-09 16:43

@menfie

Install make (pacman -S make)

fakeroot is also needed if you do not have it (I had to install it as well)

pacman -S fakeroot