On 2022-02-16, Andrea Pappacoda wrote: > Hi, I think that CMAKE_SKIP_RPATH a bit extreme too. Also, setting both > options doesn't make much sense, as CMAKE_SKIP_RPATH completely avoids > setting the rpath, so CMAKE_BUILD_RPATH_USE_ORIGIN does nothing :/
Well, it makes it "easy" to fallback to CMAKE_BUILD_RPATH_USE_ORIGIN, but I think in this case that CMAKE_BUILD_RPATH_USE_ORIGIN should be the default... > If you really want to avoid having an rpath in the installed package > you could set the CMAKE_SKIP_INSTALL_RPATH option, that strips the > rpath on install (it may be enabled by default, I'm not sure) but keeps > it in the build tree so that you can run tests without having to mess > with env vars. Using CMAKE_SKIP_INSTALL_RPATH still results in a different BuildId embedded in the binary when built under a different build path. Even though the build path is eventually removed, the BuildId is calculated before it is removed... > But if what you are trying to solve is a reproducibility issue then > CMAKE_BUILD_RPATH_USE_ORIGIN should be enough, and shouldn't even > break existing workflows. That's been my experience so far, I've confirmed this with buidl testing for many of the ~160 packages documented at: https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html live well, vagrant
signature.asc
Description: PGP signature
