https://bugs.kde.org/show_bug.cgi?id=526075
Mark Wielaard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED --- Comment #3 from Mark Wielaard <[email protected]> --- (In reply to yegorich from comment #2) > A real user would hit it if they chose -O0 for their whole system > and also enabled valgrind. That's not unreasonable, since people debugging > their system are the ones who want valgrind. OK, thanks. That seems like enough justification. The patch should really not impact any other setup. So pushed with bug references in NEWS and commit message: commit 0ff27aab0831786c7f419e73a2b5217cbbcc792d Author: Yegor Yefremov <[email protected]> Date: Mon Sep 21 23:45:52 2026 +0200 Provide dummy unwinder entry points needed by libgcc The 64 bit division helpers of libgcc (__divdi3 and friends) are compiled with -fexceptions -fnon-call-exceptions. When libgcc is built without optimisation, GCC keeps the exception landing pads in those objects, so _divdi3.o, _moddi3.o and _umoddi3.o end up referencing _Unwind_Resume() and __gcc_personality_v0(), which normally live in libgcc_eh.a. At -O1 and above the landing pads are optimised away and the references are gone. Tools are linked with -static -nodefaultlibs and pull the 64 bit division helpers out of -lgcc, but libgcc_eh.a is not available, so linking a tool against such a libgcc fails with: ld: libgcc.a(_divdi3.o): in function `__divdi3': libgcc2.c:1226: undefined reference to `_Unwind_Resume' ld: libgcc.a(_divdi3.o):(.data.rel.local.DW.ref.__gcc_personality_v0[DW.ref.__gcc_personality_v0]+0x0): undefined reference to `__gcc_personality_v0' ld: libgcc.a(_moddi3.o): in function `__moddi3': libgcc2.c:1249: undefined reference to `_Unwind_Resume' ld: libgcc.a(_umoddi3.o): in function `__udivmoddi4': libgcc2.c:1204: undefined reference to `_Unwind_Resume' collect2: error: ld returned 1 exit status Provide dummy definitions. They can never be reached, since the core is plain C and never raises an exception. They live in libgcc-sup-<platform>.a, which is linked after -lgcc, so toolchains that do provide the real symbols keep using those. https://bugs.kde.org/show_bug.cgi?id=526075 Signed-off-by: Yegor Yefremov <[email protected]> -- You are receiving this mail because: You are watching all bug changes.
