Package: release.debian.org Severity: normal X-Debbugs-Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Control: affects -1 + src:suricata User: [email protected] Usertags: riscv64 User: [email protected] Usertags: binnmu
Hello release team, riscv64 porters, libunwind maintainer Adrian and suricata maintainer Sascha, I am requesteing a binNMU of suricata for riscv64 only. nmu suricata_1:8.0.4-1 . riscv64 . unstable . -m "Rebuild to link libgcc_s" This all started with me trying to get doxysphinx into testing and ended up shaving a herd of yaks. doxysphinx was is transitively blocked by python-memray, which has its autopkgtest fail. It segfaults on amd64. Luckily Stefano managed to get upstream attention (https://github.com/bloomberg/memray/issues/863) and they identified that some symbols were provided by both libunwind and libgcc_s in mutually incompatible ways. Things would typically work out as any single program would pick either libgcc_s' implementation or libunwind's. That is unless one were dlopen()ing a library that ends up linking libunwind. Then, the program could start with the libgcc_s implementation and then switch over to libunwind. This is exactly what happened to the Python interpreter when it loaded memray's C extension. Now having libunwind and libgcc_s provide the same functions in incompatible way is very bad to start with. This is why libunwind upstream recommends disabling those symbols. The feature to disable is C++ exception support in libunwind. By default, this is disabled for X86, but it ended up being enabled for clang's libc++ (#682194). Meanwhile, clang uses its own libunwind (which is why we have several now). We also run into ran into other problems such as https://github.com/libunwind/libunwind/issues/925 as a result of having C++ exception support enabled in Debian. I researched what others do and found that Fedora leaves C++ exception support disabled. I eventually reached the conclusion that Debian's libunwind really should not be enabling C++ exception support (following the upstream recommendation and Fedora) and also discussed this with Stefano and Julian. Disabling this support would immediately fix the python-memprof as a build on debusine.debian.net confirmed. It also showed no reverse dependency autopkgtest regressions. In principle, disabling C++ exception support is an ABI break as it removes symbols from libunwind. However, we cannot bump soname and we should never have enabled this. Hence, I went ahead and NMUed libunwind. Then suricata's autopkgtest regressed on riscv64. That's an architecture not covered by debusine.debian.net. And this is where we close in on the binNMU request. suricata now ends up missing the symbol _Unwind_GetLanguageSpecificData. Bummer. Why is this different from X86? It turns out that suricata links libgcc_s on X86, but not on riscv64. I guess that since we use -Wl,--as-needed libgcc_s was identified as unused on riscv64 and dropped whereas X86 needs more libgcc_s symbols and was kept. I locally verified that rebuilding suricata in unstable would make it link libgcc_s. So while this is an ABI break, it only affects suricata on riscv64 in Debian. It may break stuff outside Debian, but any binary that we'd break would also be broken on Fedora. Thus I propose a binNMU of suricata followed by an upload of libunwind that Breaks: suricata (<< 1:8.0.4-1+b1) [riscv64]. I intend to NMU libunwind to add these breaks if you agree and schedule the binNMU. Doing this should finally migrate a significant chunk of packages to forky.. Helmut
