Steven Chamberlain wrote: > Upgrading libc0.1 breaks pretty much everything: Actually not everything. It broke the buildd though, because dpkg-deb stopped working. This was from dpkg-deb: > | Core was generated by `ld-2.22.so'. > | Program terminated with signal 4, Illegal instruction. > | (gdb) bt full > | #0 0x0100622b in ?? () > | No symbol table info available. > | #1 0x62696c2f in ?? () > | No symbol table info available. > | #2 0x3833692f in ?? () > | No symbol table info available. > | #3 0x666b2d36 in ?? () > | No symbol table info available. > | #4 0x01001a90 in ?? () > | No symbol table info available. > | #5 0x00000000 in ?? () > | No symbol table info available. It fails trying to map shared object liblzma.so.5: | 2494 ld.so.1 NAMI "/usr/bin/dpkg-deb" | ... | 2494 ld.so.1 NAMI "/lib/i386-kfreebsd-gnu/libz.so.1" | 2494 ld.so.1 NAMI "/lib/i386-kfreebsd-gnu/liblzma.so.5" | ... | 2494 ld.so.1 PSIG SIGILL SIG_DFL code=ILL_PRVOPC There is something special about liblzma.so.5: | STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 | filesz 0x00000000 memsz 0x00000000 flags rwx It requires a writable and executable stack! which is rather rare, and probably should be fixed in the affected libraries. The kfreebsd buildds have disallowed executable stacks since DebConf15 though. I'm not sure why glibc 2.22 causes any regression here; this code has not changed since 2.21, but maybe something related to DEFAULT_STACK_PERMS, PF_X or PT_GNU_STACK has changed recently. Regards, -- Steven Chamberlain steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature