| Version annotated: |
2021.10-4 |
|
Identified issues:
|
|
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.
|
|
Identifier:
|
nondeterministic_ordering_in_documentation_generated_by_doxygen
|
|
Description
|
"Additional Inherited Members" has nondeterministic children in the (HTML?)
docs.
.
This can also happen when there is a real C function and a hash-define with
the same name. Doxygen sorts the member names but it only appears to use
the name so it is not stable relative to their type, resulting in
nondeterministic output.
.
MemberNameSDict::compareValues in doxygen's membername.cpp is suspicious.
|
|
|
Comments:
|
rpath issue fixed by -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
.
embedded timestamp, probably via compileTimestamp function in
opm/simulators/utils/moduleVersion.cpp.
|
| |
|
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).
|