Version annotated: |
16.04.3-1 |
Identified issues:
|
Identifier:
|
build_id_variation_requiring_further_investigation
|
Description
|
ld adds a Build ID in ELF binaries used to link external debug symbols. See https://fedoraproject.org/wiki/Releases/FeatureBuildId#Unique_build_ID for the spec. The default value is a SHA1 hash over the content of the binary. See the `--build-id` option in https://sourceware.org/binutils/docs-2.25/ld/Options.html for other behavior. Unless a different way to compute Build IDs has been specified, different Build IDs are the symptom of different binary content. The actual source of the difference might not be visible because the debug symbols might have been stripped (and they can contain filenames which can differ if the build path is different). There is no general solution for this problem. The source of the variation must be tracked and fixed. The issue can come from variations in order of object members or objects themselves, different content (e.g. `__DATE__` CPP macros or similar), or other interesting things.
|
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).
|