Notes about issue cmake_rpath_contains_build_path in experimental
Identifier: | cmake_rpath_contains_build_path |
---|---|
Suites: | unstable / trixie / bookworm / bullseye / experimental |
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. |
Packages in 'experimental' known to be affected by this issue: (the 1/4 most-popular ones (within this issue) are underlined) |
32 reproducible packages in experimental/amd64:
5 FTBFS packages in experimental/amd64:
2 unreproducible packages in experimental/amd64:
1 depwait packages in experimental/amd64:
|
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). |
A package name displayed with a bold
font is an indication that this package has a note. Visited
packages are linked in green, those which have not been visited are
linked in blue.
A #
sign after the name of a package
indicates that a bug is filed against it. Likewise, a
+
sign indicates there is a
patch available, a P
means a
pending bug while #
indicates a
closed bug. In cases of several bugs, the symbol is repeated.