| Version annotated: |
2.0.11-1 |
|
Identified issues:
|
|
Identifier:
|
dynstr_section_longer_by_two_bytes_which_are_NULs
|
|
Description
|
The .dynstr section on the right build is longer by two bytes.
The value of those two bytes is 0x00 0x00.
.
stlink=1.7.0+ds-1 is currently in both bullseye and sid; is reproducible on
the former but not on the latter; and has this issue. The issue could be
caused by a difference in some build dependency between the two suites (for
some common build dependency of all packages having this issue); or by
a difference in the variations tested in the two suites.
.
The only difference in variations (per current "Variations tested" page) is
the build path variation.
.
If the package uses the cmake buildsystem, this is likely a form
of cmake_rpath_contains_build_path issue.
.
So, is there any any chance that this issue is caused by the build path
variation? Perhaps the number of extra bytes is 2
because the build path in build #2 is two bytes longer than in build
#1?
|
|
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.
|
|
| |
|
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).
|