Package Details: rr 5.4.0-6

Git Clone URL: https://aur.archlinux.org/rr.git (read-only, click to copy)
Package Base: rr
Description: Record and Replay framework: lightweight recording and deterministic debugging
Upstream URL: http://rr-project.org/
Licenses: custom
Submitter: dequis
Maintainer: codyps (dequis)
Last Packager: codyps
Votes: 42
Popularity: 1.28
First Submitted: 2015-08-24 23:26
Last Updated: 2020-11-16 22:28

Latest Comments

1 2 3 4 5 6 Next › Last »

vlovich commented on 2021-03-09 23:24

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

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

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

@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

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: https://gist.github.com/jmesmon/4956434dd689994d1e31b603c13ec738

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

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

I assume you're not using a GNU compiler?

Also: it appears that pastebin.com 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

@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 https://github.com/rr-debugger/rr/pull/2726.

Backporting the relevant commit works for me, pastebin with my local patch doing exactly that here for reference: https://pastebin.com/qPkS18eF

codyps commented on 2019-12-04 05:55

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

chetgurevitch commented on 2019-12-03 21:50

@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 {} + || :
fi

to package()

1: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/valgrind

tbodt commented on 2019-11-26 17:21

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

codyps commented on 2019-08-20 17:38

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