| Version annotated: |
0.3-2 |
|
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).
|