On 2020-06-29, Timo Röhling wrote: >>> By default, CMake adds an RPATH entry to ELF binaries and deletes it >>> again at install time. However, due to the limitations of some >>> platforms, CMake will actually zero out the RPATH entry in the binary, >>> leaking the original path length and thus making the build not >>> reproducible (see the attached diffoscope output for an example). >>> >>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and >>> since most package won't ever ship with an RPATH entry anyway, I propose >>> adding -DCMAKE_SKIP_RPATH=ON to the default build options. >> Thanks for the suggestion.
Thanks for identifying the issue! >> Has this proposal been tested on an archive-wide rebuild test to see how >> much breaks with this option set? > I don't know, but I don't think so. I'm not directly involved with the > Reproducible Builds Team, I just pinged them on IRC after I filed this > bug. Cc'ing them now. There is currently only one package tagged with: https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html The tagging is not automated, so most likely there are more issues that people have not yet been identified... any good search terms for sources.debian.org that might produce a list to compare? The tests.reproducible-builds.org infrastructure has been building without any custom toolchains for quite a while now, but we did at one point have the ability to build with custom packages. It is best to be avoided, however, as then we have to constantly keep pace with whatever tools we're patching... It would be nice if this could be added to debhelper but disabled by default unless a flag was set in DEB_BUILD_OPTIONS (or something similar) so that we could enable it from the build environment in reproducible builds test infrastructure without affecting the official archive. live well, vagrant
signature.asc
Description: PGP signature
