Fix static binary - #4983
Fix static binary#4983
Conversation
#4929 swapped the deps/elfutils submodule for the system libdw, dropping the --disable-libdebuginfod --disable-debuginfod it was configured with, and the comment saying why: We need to disable libdebuginfod or the static binary will try and load it at runtime and pull in incompatible libs it depends on on whatever system it's running on. Distro libdw has debuginfod enabled, and elfutils dlopens libdebuginfod.so.1 from a constructor before main. In a -static binary that maps the host's libc.so.6 in beside the one we linked and dies in __ctype_init, so every invocation segfaults. v1.76.0 does this on a glibc 2.39 host; v1.75.1, the last release before the change, does not. Restoring the rule needs the two libraries 0.195 split out and the 0.186 layout it was written for did not have: libeu (eu_tsearch and friends) and libdwfl_stacktrace (dwflst_tracker_cache_elf). Both were already built by the rule, neither was installed or linked. The submodule points at github.com/vgteam/elfutils, not sourceware, which answers the CI runners' shared IPs with HTTP 429 on the recursive submodule fetch and fails the job before it compiles anything. Same commit, mirrored. Verified by a full static build from clean on Ubuntu 26.04 (GNU Make 4.4.1, gcc 15.2, glibc 2.43) and on 22.04: no libdebuginfod string in the binary, and it runs on a glibc 2.39 host where both v1.76.0 and an unpatched local build segfault.
83c5267 to
2bdb4d6
Compare
|
Sorry! If we don't want to only rely on the more-strongly-worded comment (which probably will work), we would want to add something to the CI tests that tries out the static binary on an older (or at least different) distro/glibc than it is built on. This is not the first time elfutils has reorganized everything on us; maybe depending on a bunch of details of the layout of an 0.xxx project is a bad idea. We could look at https://github.com/bombela/backward-cpp#libraries-to-read-the-debug-info and do some testing and see if we can't move to... maybe libdwarf, since while the one in Ubuntu also is in 0.x at least there are supposedly several API-compatible implementations. IIRC I tested a bunch of them a long time ago and could really only get libdw working, but maybe that's changed. I think we might strip most of the good stuff that this reads when we |
2 participants
vg 1.76.0 doesn't work on my computer at home. This reproduces when I
make staticon mustard. Seems likely that it'll affect other users as well.It seems that this was a known issue before, and the work-around was undone in #4929 in an effort to add support for Ubuntu 26. This caused a regression that apparently broke binary compatiblity.
This PR reverts this change, bringing back the submodule, and fixing the build for it. It will necessitate at patch release.
Some more details from the chatbot who did the work:
#4929 swapped the deps/elfutils submodule for the system libdw, dropping the --disable-libdebuginfod --disable-debuginfod it was configured with, and the comment saying why:
Distro libdw has debuginfod enabled, and elfutils dlopens libdebuginfod.so.1 from a constructor before main. In a -static binary that maps the host's libc.so.6 in beside the one we linked and dies in __ctype_init, so every invocation segfaults. v1.76.0 does this on a glibc 2.39 host; v1.75.1, the last release before the change, does not.
Restoring the rule also needs the two libraries 0.195 split out and the 0.186 layout it was written for did not have: libeu (eu_tsearch and friends) and libdwfl_stacktrace (dwflst_tracker_cache_elf). Both were already built by the rule, neither was installed or linked. That is probably why #4929 gave up on the submodule, since b87ebaa bumped 0.186 -> 0.195 a few commits earlier and would have broken the link exactly this way.
Verified by a full static build from clean on Ubuntu 26.04 (GNU Make 4.4.1, gcc 15.2, glibc 2.43) and on 22.04: no libdebuginfod string in the binary, and it runs on a glibc 2.39 host where both v1.76.0 and an unpatched local build segfault.
Changelog Entry
To be copied to the draft changelog by merger:
Description