Version annotated: |
1.4-1 |
Identified issues:
|
Identifier:
|
captures_build_path_via_assert
|
Description
|
Absolute paths to source file names are embedded through assert(), which embeds the value of the __FILE__ macro in the .data section, or via filenames in debug symbols, which shows in the .text and .debug_str sections. . We have a pending patch to GCC to fix this in one central place. . https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html . If/when this is accepted, this issue should be fixed for all packages and you should not need to fix it specifically in your package. . For more background information see: . • https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20160822/006788.html • https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20160905/006984.html • https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20160912/007076.html
|
Identifier:
|
cmake_rpath_contains_build_path
|
URL
|
https://gitlab.kitware.com/cmake/cmake/issues/18413
|
Description
|
When an executable is linked with a shared library from the same project, RPATH will contain the build path. Even if this is stripped on installation, the build-id will remain unchanged. . With CMake 3.14+, packages can set `-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON` to fix the issue. This is done automatically when using the currently experimental debhelper compat level v14. https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH_USE_ORIGIN.html . When working with older CMake versions, the `CMAKE_SKIP_RPATH` option can be enabled instead, but it may be required to also set `LD_LIBRARY_PATH` while running tests.
|
|
Comments:
|
rpath issue fixed by -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
|
|
Our notes about issues affecting packages are stored in notes.git and are targeted at packages in Debian in 'unstable/amd64' (unless they say otherwise).
|