Debian Patches
Status for libkdumpfile/0.5.6-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| drop-bfd-true-false-macros.diff | Drop use of removed bfd TRUE/FALSE macros binutils 2.46 removed the legacy TRUE/FALSE macros (and bfd_boolean) from its public headers; the second argument of disassembler() is now a plain C bool. kdumpid still passed TRUE/FALSE, and the disassembler detection in m4/tools.m4 did the same in its conftest, so both failed to compile with binutils >= 2.46 ("'FALSE' undeclared"). . Use the integer literals 0/1 instead, which are valid for both the old bfd_boolean and the new bool parameter type, keeping compatibility with older binutils. |
Michel Lind <michel@michel-slm.name> | yes | upstream | 2026-06-19 | |
| kdumpid-static-link-binutils-libs.diff | kdumpid: statically link binutils-private libbfd/libopcodes libbfd, libopcodes and libiberty are explicitly private libraries of the binutils project: they have no stable ABI and ship without a versioned SONAME (libbfd/libopcodes live under a Debian-private name such as libbfd-2.46-system.so in libbinutils). Linking kdumpid against them dynamically gives libkdumpfile-utils a fragile dependency on libbinutils that, after a binutils upload, makes the package fail to install. . Link these libraries statically instead, using the GNU ld -l:NAME.a syntax, listed in dependency order. Their remaining dependencies (libsframe, libz, libzstd) are ordinary versioned shared libraries and stay dynamic. . The upstream KDUMP_DIS_ASM_CHECK_UNDEF autodetection cannot be reused here: it decides which libraries to add by matching undefined symbols like "bfd_" in the linker output, but a static link surfaces "_bfd_error_handler" and "_sch_istable" (libiberty safe-ctype) instead, so it would add nothing and the link would fail. The libraries are therefore listed explicitly. |
Michel Lind <michel@michel-slm.name> | not-needed | debian | 2026-06-19 |