Package Details: rr 5.5.0-1

Git Clone URL: (read-only, click to copy)
Package Base: rr
Description: Record and Replay framework: lightweight recording and deterministic debugging
Upstream URL:
Licenses: custom
Submitter: dequis
Maintainer: codyps
Last Packager: codyps
Votes: 51
Popularity: 0.74
First Submitted: 2015-08-24 23:26 (UTC)
Last Updated: 2021-09-28 19:06 (UTC)

Latest Comments

chipbuster commented on 2022-02-09 20:53 (UTC) (edited on 2022-02-09 20:54 (UTC) by chipbuster)

I'm hitting a strange issue with this PKGBUILD that is almost certainly partially caused by configuration on my end, but I don't understand what's going wrong.

I can build and install this package just fine. When I try to record with the version that's been installed into /usr/bin, I get an assertion failure and crash.

However, when I record with the version that's in pkg in the build directory, everything works fine. Even more mysteriously, when I tried to make a Docker to reproduce the bug, both the rr at /usr/bin/rr and the one within pkg can successfully record a trace! (Also, when running makepkg/pacman -U in Docker, rr gets installed into /usr/sbin for reasons that I don't understand).

Does anyone have any clue what might be going on here, or how I can further narrow down what the root cause of this is?

vlovich commented on 2021-03-09 23:24 (UTC)

Gotcha. That makes sense. I was just comparing against rr-git which used -DCMAKE_BUILD_TYPE=Release.

codyps commented on 2021-03-09 22:37 (UTC)

@vlovich: I could have sworn that build type was suggested at some point as the right way to disable flags getting added, but you're right that there doesn't appear to be any documentation on it to speak of.

Based on, it looks like using CMAKE_BUILD_TYPE=None is really the intention (well, maybe. cmake projects are complicated).

In general, Release and RelWithDebInfo aren't what we want to package though: we expect the cflags/etc to be provided via the user's makepkg.conf (or similar) rather than setting debuginfo/opt-level flags in the PKGBUILD directly.

vlovich commented on 2021-03-09 22:17 (UTC)

I see CMAKE_BUILD_TYPE=plain in the PKGBUILD for this but shouldn't that be Release or RelWithDebInfo? I'm not familiar with the "plain" build type & I don't see that referenced anywhere in the upstream repo.

konsonanz commented on 2020-11-16 22:35 (UTC)

@codyps: Thanks for the quick fix! You're right, I'm using clang and libc++ for builds against the host toolchain. A build in a clean and default chroot worked without problems.

Regarding the pastebin issue, seems like something went wrong there as I also can't (re-)apply the diff there due to some corruption error. Will take better care/test beforehand next time.

codyps commented on 2020-11-16 22:17 (UTC) (edited on 2020-11-16 22:26 (UTC) by codyps)

Hmm... curiously, cmake 3.18.4 and rr 5.4.0 seems to work fine for me. That's what I built this release with.

Log snippet:

It looks like it's probably fine for me because of this bit:

  # Gcc generates bogus R_386_GOTOFF relocations in .debug_info which
  # lld 9 rejects
  set(LINKER_FLAGS "-fuse-ld=bfd")

I assume you're not using a GNU compiler?

Also: it appears that mangles patches/diffs uploaded to it. I wasn't able to git apply yours. I've pushed a change that should fix things though.

konsonanz commented on 2020-11-16 22:01 (UTC) (edited on 2020-11-16 22:02 (UTC) by konsonanz)

@codyps: Version 5.4.0 is currently not buildable with cmake 3.18.4 (current stable version as of writing).

There is already a patch upstream, which did not make the release, at

Backporting the relevant commit works for me, pastebin with my local patch doing exactly that here for reference:

codyps commented on 2019-12-04 05:55 (UTC)

Thank you. I have taken the valgrind PKGBUILD's approach here.

chetgurevitch commented on 2019-12-03 21:50 (UTC) (edited on 2019-12-03 22:01 (UTC) by chetgurevitch)

@codyps You can do what the valgrind maintainer did [1], add !strip to options and add

if check_option 'debug' n; then
  find "${pkgdir}/usr/bin" -type f -executable -exec strip $STRIP_BINARIES {} + || :

to package()


tbodt commented on 2019-11-26 17:21 (UTC)

@codyps: must not be stripped, or you get incorrect backtraces while replaying. If there's a way to only avoid stripping, that would work.

codyps commented on 2019-08-20 17:38 (UTC)

Hi @daurnimator, thanks for pointing that out. I've dropped that dependency in rev 4.

daurnimator commented on 2019-08-19 04:02 (UTC)

rr should no longer need the python2 dependency (via python2-pexpect). It's the only thing left on my system keeping python2 installed.

codyps commented on 2019-01-02 00:26 (UTC)

Hi @Amanieu: while that could certainly be added to the PKGBUILD, it isn't entirely clear to me that this is the right thing to do: generally, one would modify the options=() via makepkg.conf to adjust behavior on one's own system.

Is there some reason should be treated specially?

Amanieu commented on 2018-12-31 22:59 (UTC)

Can you add options=(!strip) so that we can get proper backtraces from

pmatos commented on 2018-11-16 12:42 (UTC)


.cache/yay/rr/src/rr-5.2.0/src/ error: static assertion failed: type ::ucontext_t not correctly defined
   static_assert(Verifier<arch_, system_type_, rr_type_>::same_size,            \
/home/pmatos/.cache/yay/rr/src/rr-5.2.0/src/kernel_abi.h:1813:3: note: in expansion of macro ‘RR_VERIFY_TYPE_ARCH’
   RR_VERIFY_TYPE_ARCH(SupportedArch::x86_64, ::ucontext_t, ucontext_t);
make[2]: *** [CMakeFiles/rr.dir/build.make:413: CMakeFiles/rr.dir/src/] Error 1

during build with gcc8

pmatos commented on 2018-11-16 12:42 (UTC)

Missing dependency lib32-gcc-libs

for the cross-compile-toolchain

codyps commented on 2018-11-06 19:15 (UTC) (edited on 2019-08-22 17:37 (UTC) by codyps)

Here's a patch that fixes a bunch of build/install issues with the pkgbuild:

(right now it fails to build, and then fails to install on current archlinux. please apply this fix)

From 498b62863b068be5bf8b647e53b6ffe23a4ab92c Mon Sep 17 00:00:00 2001
From: Cody Schafer <>
Date: Tue, 6 Nov 2018 14:12:46 -0500
Subject: [PATCH] fix build

 - add patch for ucontext build failure from upstream
 - define CXX standard 14
 - set libdir as `lib` to avoid use of `lib64`
 .SRCINFO |  7 ++++---
 PKGBUILD | 20 ++++++++++++++++----
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/.SRCINFO b/.SRCINFO
index 63c7f2a..b137073 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,9 +1,7 @@
-# Generated by mksrcinfo v8
-# Mon May 28 00:53:20 UTC 2018
 pkgbase = rr
    pkgdesc = Record and Replay framework: lightweight recording and deterministic debugging
    pkgver = 5.2.0
-   pkgrel = 1
+   pkgrel = 2
    url =
    arch = i686
    arch = x86_64
@@ -11,11 +9,14 @@ pkgbase = rr
    makedepends = git
    makedepends = cmake
    makedepends = gdb
+   makedepends = gcc-multilib
    depends = python2-pexpect
    depends = gdb
    depends = capnproto
    source =
+   source =
    sha1sums = 55040be15a87dd93012d7cdbeb8a3fc428ea4b6b
+   sha1sums = 9fcafcc3f4474b4352402b39002869a51e77f6df

 pkgname = rr

diff --git a/PKGBUILD b/PKGBUILD
index e32fa8f..43ed499 100644
@@ -3,7 +3,7 @@

 pkgdesc='Record and Replay framework: lightweight recording and deterministic debugging'
 arch=(i686 x86_64)
@@ -11,17 +11,29 @@ license=('custom')
 depends=('python2-pexpect' 'gdb' 'capnproto')
 makedepends=('git' 'cmake' 'gdb')
 [ "$CARCH" = 'x86_64' ] && makedepends+=('gcc-multilib')
+          '9fcafcc3f4474b4352402b39002869a51e77f6df')

 prepare() {
    cd $pkgname-$pkgver
    mkdir -p build
+   patch -Np1 -i "$srcdir/53c5bd72bae089616a3ca626b8af240481d70e6f.patch"

 build() {
    cd $pkgname-$pkgver/build
+   cmake \
+       -DCMAKE_BUILD_TYPE=RelWithDepInfo \
+       ..


YaLTeR commented on 2018-09-12 11:34 (UTC)

Looks like it was fixed upstream:

YaLTeR commented on 2018-09-12 10:20 (UTC) (edited on 2018-09-12 10:20 (UTC) by YaLTeR)

I'm getting the following build error:

/home/yalter/.cache/pacaur/rr/src/rr-5.2.0/src/ error: static assertion failed: type ::ucontext_t not correctly defined
   static_assert(Verifier<arch_, system_type_, rr_type_>::same_size,            \

/home/yalter/.cache/pacaur/rr/src/rr-5.2.0/src/kernel_abi.h:1813:3: note: in expansion of macro ‘RR_VERIFY_TYPE_ARCH’
   RR_VERIFY_TYPE_ARCH(SupportedArch::x86_64, ::ucontext_t, ucontext_t);

desmu commented on 2018-07-27 16:36 (UTC)

For those who don't want the bit version or don't have the cross compiling tool chain:

add -Ddisable32bit=ON on line 24 in PKGBUILD.

dequis commented on 2018-05-28 00:55 (UTC)

5.2.0 is out

Also disabled tests, thanks tbodt.

tbodt commented on 2018-05-22 21:26 (UTC) (edited on 2018-05-22 21:28 (UTC) by tbodt)

Build times could be sped up roughly 10x by adding -DBUILD_TESTS=OFF -DWILL_RUN_TESTS=OFF to the CMake command.

dequis commented on 2017-12-24 17:25 (UTC) (edited on 2017-12-25 14:45 (UTC) by dequis)

Sorry about that, updated to 5.1.0 now.

capnproto is now a dependency so that recordings can be compatible across updates. Still an AUR only package but it's getting moved to [community] soon. EDIT: now in [community], yay!


flacks commented on 2017-12-24 16:50 (UTC)

Here's an updated PKGBUILD for 5.1.0 -

LawnGnome commented on 2017-06-22 21:25 (UTC)

I see the same issue. Here are the SHA-1 sums I see (the first two patch files being the ones that don't match the PKGBUILD): [aharvey@aharvey-mbp-linux rr]$ sha1sum *.patch 51dba5dbbe16c3631a101409a28247075668fe7b 2001.patch 401ca2e7108fc305c6644c2d27a86fdb24855fb1 5a16d15ef348c069b82449dcdeaeea3c1eb8639b.patch 7724dbd8c1231410c62a7779ef480857c661882a 94685aa9eb3531c42932f8ceabe40bd06cebe606.patch I've uploaded the files to a Gist:

dequis commented on 2017-06-20 17:47 (UTC)

It works for me for newly downloaded patches. Can you upload the ones you got?

codyps commented on 2017-06-20 16:10 (UTC) (edited on 2017-06-20 16:11 (UTC) by codyps)

I'm seeing build failures in 4.5.0-4 due to sha1sum mismatches. May be a good idea to just include the patches in the aur package repo directly. ==> Making package: rr 4.5.0-4 (Tue Jun 20 12:08:47 EDT 2017) ==> Retrieving sources... -> Found 4.5.0.tar.gz -> Found 2001.patch -> Found 5a16d15ef348c069b82449dcdeaeea3c1eb8639b.patch -> Found 94685aa9eb3531c42932f8ceabe40bd06cebe606.patch ==> Validating source files with sha1sums... 4.5.0.tar.gz ... Passed 2001.patch ... FAILED 5a16d15ef348c069b82449dcdeaeea3c1eb8639b.patch ... FAILED 94685aa9eb3531c42932f8ceabe40bd06cebe606.patch ... Passed ==> ERROR: One or more files did not pass the validity check! :: failed to verify rr integrity

dequis commented on 2017-06-10 15:52 (UTC)

-index 60de6e4..bb5b527 100644 +index 60de6e47..bb5b527c 100644 Wow that's annoying. It's the new git feature which increases the length of hashes depending on the repository size. Fixed in 4.5.0-4. Also added another patch to build with GCC 7 ( )

harmathy commented on 2017-06-10 14:16 (UTC)

Sha1 sums don't match anymore: ==> Making package: rr 4.5.0-3 (Sat Jun 10 16:14:51 CEST 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found 4.5.0.tar.gz -> Found 2001.patch -> Found 5a16d15ef348c069b82449dcdeaeea3c1eb8639b.patch ==> Validating source files with sha1sums... 4.5.0.tar.gz ... Passed 2001.patch ... FAILED 5a16d15ef348c069b82449dcdeaeea3c1eb8639b.patch ... FAILED ==> ERROR: One or more files did not pass the validity check!

dequis commented on 2017-03-21 20:31 (UTC)

4.5.0-3 backports another patch to fix build with glibc 2.25

dequis commented on 2017-03-21 07:27 (UTC)

Thanks, 4.5.0-2 now includes that whole pull request as a patch.

janisozaur commented on 2017-03-21 07:07 (UTC)

Fixed upstream in and You can work around that by either applying these patches, not building tests (I doubt the package executes them) or disabling -Werror. The tests are actually needed to be built with debug enabled.

jneem commented on 2017-03-20 00:38 (UTC)

With gcc 6.3.1, I'm getting a failed build due to -Werror: /home/jneeman/.cache/pacaur/rr/src/rr-4.5.0/src/test/ptrace_remote_unmap.c:53:3: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] assert(wret = child); As I discovered when poking around in CMakeLists.txt, the test files are built with debug flags, even in a release build (see CMakeLists.txt:987). Maybe you could just turn off building the tests?

dequis commented on 2016-10-03 04:17 (UTC)

@chris64: that's an error raised by make, which depends on libgc. Either something broken in your system, or arch core bug. rr doesn't use libgc at all.

chris64 commented on 2016-10-02 10:31 (UTC)

gc is missing as a required dependency :-) make: error while loading shared libraries: cannot open shared object file: No such file or directory make[1]: *** [CMakeFiles/Makefile2:4974: CMakeFiles/ptrace_signals_32.dir/all] Error 127 make: *** [Makefile:161: all] Error 2

dequis commented on 2016-10-02 02:09 (UTC)

4.4.0 for real this time, release notes: The issue in my previous comment turned out to be hardening-wrapper. I've included this patch to fix it:

dequis commented on 2016-10-01 18:18 (UTC)

Not updating to 4.4.0 yet since it fails to build for me:

dequis commented on 2016-09-01 15:50 (UTC)

Fixed with 4.3.0-2. Added -DCMAKE_BUILD_TYPE=Release to build without -Werror and with -O2 (so maybe the overhead will be lower too)

damien commented on 2016-09-01 11:35 (UTC)

The compilation is failing for me with gcc 6.1.1 due to warnings being treated as errors.

dequis commented on 2016-06-30 23:09 (UTC)

4.3.0 is out, release notes:

pmderodat commented on 2016-06-08 12:51 (UTC)

@dequis I’ll indeed try to contact directly upstream maintainers. Thank you for your help!

dequis commented on 2016-06-08 10:35 (UTC)

@pmderodat #rr You might want to ask there or file an issue in the github issue tracker, I personally have no idea. At least the mentioned -Werror issue should be fixed in git, though. Downgrading gcc-multilib and gcc-libs-multilib to 5.x may also help. FWIW, here's my built package: There's also a prebuilt .tar.gz available in

pmderodat commented on 2016-06-08 10:25 (UTC)

@dequis @SilverOne Thanks for your answers! Yes, same problem in the rr-git package as well. @dequis: where did you get the info about it fixed upstream?

SilverOne commented on 2016-06-07 19:35 (UTC)

@dequis I get the same problem in the rr-git package.

dequis commented on 2016-06-03 17:39 (UTC)

@pmderodat Apparently this stuff is fixed in the master branch, try the rr-git package.

pmderodat commented on 2016-05-31 13:29 (UTC)

Hello, I just tried to build this package and get the following error: [ 42%] Building CXX object CMakeFiles/rr.dir/src/ In file included from /home/pmderodat/misc/rr/src/rr-4.2.0/src/AutoRemoteSyscalls.h:10:0, from /home/pmderodat/misc/rr/src/rr-4.2.0/src/ /home/pmderodat/misc/rr/src/rr-4.2.0/src/Registers.h: In instantiation of ‘void Registers::set_arg(T) [with int Index = 3; T = std::nullptr_t]’: /home/pmderodat/misc/rr/src/rr-4.2.0/src/AutoRemoteSyscalls.h:224:30: recursively required from ‘void AutoRemoteSyscalls::syscall_helper(int, Registers&, T, Rest ...) [with int Index = 2; T = long unsigned int; Rest = {std::nullptr_t, long unsigned int}]’ /home/pmderodat/misc/rr/src/rr-4.2.0/src/AutoRemoteSyscalls.h:224:30: required from ‘void AutoRemoteSyscalls::syscall_helper(int, Registers&, T, Rest ...) [with int Index = 1; T = int; Rest = {long unsigned int, std::nullptr_t, long unsigned int}]’ /home/pmderodat/misc/rr/src/rr-4.2.0/src/AutoRemoteSyscalls.h:155:5: required from ‘long int AutoRemoteSyscalls::infallible_syscall(int, Rest ...) [with Rest = {int, long unsigned int, std::nullptr_t, long unsigned int}]’ /home/pmderodat/misc/rr/src/rr-4.2.0/src/ required from here /home/pmderodat/misc/rr/src/rr-4.2.0/src/Registers.h:238:51: error: parameter ‘value’ set but not used [-Werror=unused-but-set-paramete] template <int Index, typename T> void set_arg(T value) { ^~~~~ cc1plus: all warnings being treated as errors CMakeFiles/rr.dir/build.make:846: recipe for target 'CMakeFiles/rr.dir/src/' failed make[2]: *** [CMakeFiles/rr.dir/src/] Error 1 CMakeFiles/Makefile2:11117: recipe for target 'CMakeFiles/rr.dir/all' failed make[1]: *** [CMakeFiles/rr.dir/all] Error 2 Makefile:160: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... I’m surprised that rr uses -Werror for production builds as this may break the build with toolchain upgrades. Actually even if I patch the root CMakeLists.txt file to remove the -Werror flag, I get a build error for missing math.h include: [ 50%] Building CXX object CMakeFiles/rr.dir/src/ /home/pmderodat/misc/rr/src/rr-4.2.0/src/ In function ‘void sleep_time(double)’: /home/pmderodat/misc/rr/src/rr-4.2.0/src/ error: ‘floor’ was not declared in this scope ts.tv_sec = (time_t)floor(t); ^ /home/pmderodat/misc/rr/src/rr-4.2.0/src/ In member function ‘void Scheduler::maybe_reset_high_priority_only_intervals(double)’: /home/pmderodat/misc/rr/src/rr-4.2.0/src/ error: ‘pow’ was not declared in this scope pow(high_priority_only_duration_step_factor, duration_step); ^ /home/pmderodat/misc/rr/src/rr-4.2.0/src/ In member function ‘bool Scheduler::in_high_priority_only_interval(double)’: /home/pmderodat/misc/rr/src/rr-4.2.0/src/ error: ‘fmod’ was not declared in this scope high_priority_only_intervals_period); ^ /home/pmderodat/misc/rr/src/rr-4.2.0/src/ In member function ‘double Scheduler::interrupt_after_elapsed_time() const’: /home/pmderodat/misc/rr/src/rr-4.2.0/src/ error: ‘floor’ was not declared in this scope high_priority_only_intervals_period) + ^ CMakeFiles/rr.dir/build.make:1038: recipe for target 'CMakeFiles/rr.dir/src/' failed Can anyone reproduce these?

severen commented on 2015-12-22 14:46 (UTC)

The dependencies libpfm4 and libdisasm are not required, the python2-pexpect dependency should be under checkdepends and there should a check() function that runs the tests. I've updated your pkgbuild here:

dequis commented on 2015-11-04 16:46 (UTC)

Done. Also updated to 4.0.1. (I actually had the /usr thing staged locally and forgot to commit it. Welp.)

Mic92 commented on 2015-11-04 15:08 (UTC) (edited on 2015-11-04 15:09 (UTC) by Mic92)

Please install rr to /usr instead of /usr/local cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. And add a dependency on gcc-multilib.

janisozaur commented on 2015-11-02 20:36 (UTC)

@vale have you tried installing gcc-multilib?

vale commented on 2015-11-02 20:15 (UTC)

I'm getting some errors during ./configure: > CMake Error at CMakeLists.txt:35 (message): > Your toolchain doesn't support 32-bit cross-compilation. A comment in CMakeLists.txt says the following: > # Check that a 32-bit cross-compile works. This is needed regardless > # of whether the entire build is being built 32-bit. Any thoughts on correcting this?

janisozaur commented on 2015-10-25 12:18 (UTC)

Python complained about that package missing, but I see that today both python2-pexpect and python2-ptyprocess were updated. Perhaps they fixed that? The error I was getting before I installed this package was: (from cmake) -- Found PythonInterp: /usr/bin/python2.7 (found suitable version "2.7.10", minimum required is "2.7") Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.7/site-packages/pexpect/", line 75, in <module> from .pty_spawn import spawn, spawnu File "/usr/lib/python2.7/site-packages/pexpect/", line 11, in <module> import ptyprocess ImportError: No module named ptyprocess CMake Error at CMakeLists.txt:103 (message): Couldn't find required Python module pexpect.

dequis commented on 2015-10-24 22:48 (UTC)

@janisozaur: I don't have that dependency and it works for me. What error are you getting?

janisozaur commented on 2015-10-24 22:18 (UTC)

Requires also python2-ptyprocess

dequis commented on 2015-10-23 09:43 (UTC)

Updated to 4.0.0