| Version annotated: |
1.4.2 |
|
Identified issues:
|
|
Identifier:
|
build_id_differences_only
|
|
Description
|
The Build ID differs, but there are no other differences.
.
Specifically, NT_GNU_BUILD_ID, .gnu_debuglink, and
/usr/lib/debug/build-id/* filenames differ, but there are no other
differences.
.
[On 'sope' seen also a difference in a .GCC.command.line section; compare 'records_build_flags'.]
.
If there _are_ other differences (or if diffoscope output is truncated),
don't tag with this issue, but look for the root problem, as explained
under build_id_variation_requiring_further_investigation.
.
When this occurs on unstable but not on testing, it's likely a form
of captures_build_path. If it uses the cmake buildsystem, very
likely to be cmake_rpath_contains_build_path.
|
|
Identifier:
|
gcc_captures_build_path
|
|
Description
|
Captures build path, e.g., /build/1st/foo-42.0 v. /build/foo-42.0/2nd
Currently we vary the build path only when testing packages from unstable
and experimental, for testing and stable we recommend that rebuilds
are done in the same path as the original build.
.
dpkg-buildflags version 1.20.6+ sets -ffile-prefix-map by default
(and -fdebug-prefix-map in older versions) which fixes this issue
in many cases, but not all (see: records_build_flags).
.
There are patches submitted upstream to address this specific issue, but they
are unlikely to be merged at this point:
.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html
.
When this is accepted into GCC upstream, we could remove this note.
In the meantime, please do not remove this issue, nor mark it as deterministic,
nor untag these packages.
|
|
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.
|
|
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:
|
Passing -ffile-prefix-map appears to remove the build path, but if
the path length differs (e.g. /build/1234 vs. /build/123456), the
size of the empty padded data will still differ.
.
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).
|