Notes about issue dynstr_section_longer_by_two_bytes_which_are_NULs in bullseye
| Identifier: | dynstr_section_longer_by_two_bytes_which_are_NULs |
|---|---|
| Suites: | unstable / trixie / bookworm / bullseye / experimental |
| Description: |
The .dynstr section on the right build is longer by two bytes. The value of those two bytes is 0x00 0x00. . stlink=1.7.0+ds-1 is currently in both bullseye and sid; is reproducible on the former but not on the latter; and has this issue. The issue could be caused by a difference in some build dependency between the two suites (for some common build dependency of all packages having this issue); or by a difference in the variations tested in the two suites. . The only difference in variations (per current "Variations tested" page) is the build path variation. . If the package uses the cmake buildsystem, this is likely a form of cmake_rpath_contains_build_path issue. . So, is there any any chance that this issue is caused by the build path variation? because the build path in build #2 is two bytes longer than in build #1? |
|
Packages in 'bullseye' known to be affected by this issue: (the 1/4 most-popular ones (within this issue) are underlined) |
|
|
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.