Bug 2517606

That issue just points to it being an external problem (mixed libc or other toolchain issue). The PR doesn't fix anything; it just removes the code path that might fail immediately on import, but any other thing that might raise a C++ exception might crash in the same way.

I've distilled it down to loading the following library (note that this is far down the chain of metakernel->jupyter_client->zeromq) that causes the problem:

$ mock -r fedora-rawhide-ppc64le --install zeromq python3-matplotlib gdb
$ mock -r fedora-rawhide-ppc64le --shell --enable-network
# gdb python3
(gdb) r
>>> from ctypes import cdll                                                                                                                                                                                                                                                                
>>> lib = cdll.LoadLibrary('libzmq.so.5')
>>> from matplotlib.ft2font import FT2Font                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                           
Program received signal SIGSEGV, Segmentation fault.
_ULppc64_dwarf_find_proc_info (as=0x0, ip=140737488344128, pi=0x7fffffffcf90, need_unwind_info=need_unwind_info@entry=1, arg=0x0) at dwarf/Gfind_proc_info-lsb.c:807                                                                                                                       
807       ret = as->iterate_phdr_function (dwarf_callback, &cb_data);

(gdb) bt full
#0  _ULppc64_dwarf_find_proc_info (as=0x0, ip=140737488344128, pi=0x7fffffffcf90, need_unwind_info=need_unwind_info@entry=1, arg=0x0)
    at dwarf/Gfind_proc_info-lsb.c:807
#1  0x00007ffff654c060 in fetch_proc_info (c=c@entry=0x7fffffffcba0, ip=<optimized out>) at dwarf/Gparser.c:473
#2  0x00007ffff654d28c in _ULppc64_dwarf_make_proc_info (c=c@entry=0x7fffffffcba0) at dwarf/Gparser.c:1047
#3  0x00007ffff654d498 in _ULppc64_get_proc_info (cursor=0x7fffffffcba0, pi=pi@entry=0x7fffffffc550) at ppc/Gget_proc_info.c:35
#4  0x00007ffff654d7b0 in _Unwind_GetLanguageSpecificData (context=<optimized out>) at unwind/GetLanguageSpecificData.c:34
#5  0x00007ffff5f22e30 in __cxxabiv1::__gxx_personality_v0 (version=<optimized out>, actions=<optimized out>, 
    exception_class=<optimized out>, ue_header=<optimized out>, context=<optimized out>)
    at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:447
#6  0x00007ffff637e9c0 in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x1001c9100, context=context@entry=0x7fffffffcba0, 
    frames_p=frames_p@entry=0x7fffffffd410) at ../../../libgcc/unwind.inc:64
#7  0x00007ffff637f770 in _Unwind_Resume (exc=0x1001c9100) at ../../../libgcc/unwind.inc:242
#8  0x00007fffb00e0ab8 in ft2font__getattr__ (name=...) at ../src/ft2font_wrapper.cpp:1640
#9  0x00007fffb0103114 in pybind11::cpp_function::initialize<pybind11::object (*&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), pybind11::object, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, pybind11::name, pybind11::scope, pybind11::sibling>(pybind11::object (*&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), pybind11::object (*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), pybind11::name const&, pybind11::scope const&, pybind11::sibling const&)::{lambda(pybind11::detail::function_call&)#1}::_FUN(pybind11::detail::function_call&) ()
    at /usr/include/pybind11/cast.h:2195
...

If I load `libunwind.so.8` directly instead of `libzmq.so.5`, then it does not crash. But if I rebuild zeromq using `--without unwind`, then it also does not crash. So this has something to do with `libzmq` _with_ `libunwind` linked to it. Looking at the backtrace, we can see that we're in the C++ stdlib `__cxxabiv1::__gxx_personality_v0` but then go to `_Unwind_GetLanguageSpecificData` from `libunwind`.

Based on the linked libunwind PR/commit, it seems that C++ exception handling should not be enabled in distros. If we look at the most recent build https://koji.fedoraproject.org/koji/buildinfo?buildID=2838927, then for x86_64, we have:
> checking if C++ exception support should be built... no
but on ppc64le, we have:
> checking if C++ exception support should be built... yes

That's because the spec doesn't explicitly enable or disable the feature and it's autodetected. So we should explicitly pass the flag to disable the C++ exception feature.

The dropped symbols are:

-_Unwind_Backtrace
-_Unwind_DeleteException
-_Unwind_FindEnclosingFunction
-_Unwind_ForcedUnwind
-_Unwind_GetBSP
-_Unwind_GetCFA
-_Unwind_GetDataRelBase
-_Unwind_GetGR
-_Unwind_GetIP
-_Unwind_GetIPInfo
-_Unwind_GetLanguageSpecificData
-_Unwind_GetRegionStart
-_Unwind_GetTextRelBase
-_Unwind_RaiseException
-_Unwind_Resume
-_Unwind_Resume_or_Rethrow
-_Unwind_SetGR
-_Unwind_SetIP

_Unwind_GetBSP is not used in Fedora, and the rest are provided by libgcc_s as versioned symbols. It should be safe to configure with --disable-cxx-exceptions without an ABI transition.

I'm still waiting for a build to complete successfully. I've git a spec file change that results in the expected build configuration change.

I had to fix a bunch of s390x issues via backports to get things to build successfully.

I'm going to backport this to older Fedora releases next week.

(In reply to Florian Weimer from comment #5)
> I'm going to backport this to older Fedora releases next week.

Ping.

FEDORA-2026-6657604f4e (libunwind-1.8.3-4.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-6657604f4e

FEDORA-2026-e537df8511 (libunwind-1.8.3-4.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-e537df8511

(In reply to Fedora Update System from comment #8)
> FEDORA-2026-e537df8511 (libunwind-1.8.3-4.fc43) has been submitted as an
> update to Fedora 43.
> https://bodhi.fedoraproject.org/updates/FEDORA-2026-e537df8511

Thanks for the reminder. Builds done and Bodhi updates submitted.

FEDORA-2026-6657604f4e has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-6657604f4e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-6657604f4e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-e537df8511 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e537df8511`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e537df8511

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-6657604f4e (libunwind-1.8.3-4.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-e537df8511 (libunwind-1.8.3-4.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.