Package: debhelper Version: 13.6 Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath toolchain X-Debbugs-Cc: Vagrant Cascadian <vagr...@reproducible-builds.org>, reproducible-b...@lists.alioth.debian.org
The debhelper compat level v14 is still experimental, and I think it might be worth dropping -DCMAKE_SKIP_RPATH=on, as there are cases where it actually can trigger build failures, while -DCMAKE_BUILD_PATH_USE_ORIGIN=ON can provide all of the reproducibility benefits, with less liklihood to trigger build failures. From the debhelper manpage: The cmake buildsystem now passes -DCMAKE_SKIP_RPATH=ON and -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to cmake(1) to avoid some reproducibility issues. This can cause issues with running binaries directly from the build directories as they might now require a manually set LD_LIBRARY_PATH. If you need to override this change, we recommend that you try to pass the -DCMAKE_SKIP_RPATH=OFF option first to see if that fixes the problem (leaving CMAKE_BUILD_RPATH_USE_ORIGIN at its new default). This should undo the need for LD_LIBRARY_PATH and avoid the reproducibility issues on Linux, where $ORIGIN is supported by the runtime linkers. If -DCMAKE_SKIP_RPATH=ON was not included in the first place, this latter section could be dropped and it would be easier for affected package maintainers to adopt debhelper v14 (e.g. not having to explicitly override the default with -DCMAKE_SKIP_RPATH=OFF) while still gaining the reproducibility benefits. I am not aware of cases where having -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON but not -DCMAKE_SKIP_RPATH=ON triggers reproducibility issues. Are there issues with embedding relative RPATHs as -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON does, or other strong reasons to exclude RPATH entirely by default? live well, vagrant
signature.asc
Description: PGP signature