| Version annotated: |
2.1.4-2 |
|
Identified issues:
|
|
Identifier:
|
captures_kernel_version_via_CMAKE_SYSTEM
|
|
Description
|
Uses CMAKE_SYSTEM, which embeds `uname -sr` output; the -r (version) varies.
.
Instead, use CMAKE_SYSTEM_NAME (`uname -s`), which shouldn't vary.
.
May also be triggered by use of CMAKE_HOST_SYSTEM,
CMAKE_HOST_SYSTEM_VERSION or CMAKE_SYSTEM_VERSION.
.
Parent issue: captures_kernel_version
|
|
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:
|
Embed build time.
https://sources.debian.net/src/libcec/2.2.0%2Bdfsg1-1/configure.ac/?hl=351:255#L351
Can be removed by passing HAVE_DATE=no HAVE_WHOAMI=no HAVE_HOSTNAME=no HAVE_UNAME=no
to ./configure but the binaries are also non-deterministic.
.
rpath issue fixed by -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
.
debian/patches/03_reproducible_build.patch should use
CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM.
|
| |
|
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).
|