On Sat, Mar 21, 2026 at 08:46:55PM +0100, Helmut Grohne wrote: >... > 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. >...
C++ exception support was never enabled on riscv64. > Helmut cu Adrian
