https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Florian Weimer from comment #2) > Weak symbols have no meaning for ELF DSOs, so this wouldn't work for > libgcc_s on ELF targets. Instead we automatically link against dynamic > libgcc_s if certain symbols not in libgcc.a are referenced. Sources built > with -ftrampoline-impl=heap -fexceptions can already trigger such a > dependency for _Unwind_Resume because it's used in the cleanup handler, for > example. So if we remove these symbols from libgcc.a and then the user builds with -static-libgcc - that would just be an error (presumably at runtime if ld allows undefined symbols). I'm not clear about what the scope of "we automatically link against dynamic libgcc_s" is in that case. Assuming that omitting the symbols from libgcc.a means either linking against libgcc_s or providing them from some other source when -static-libgcc is given: - we could use a CRT for that. - I suppose we could also add these symbols to libgcc_eh for that case - but that proved to be a bad choice for emuTLS, so it would also need to be configured per platform. On platforms like Mach-O, the strategy I outlined will work OK (this is configurable per target, so should be OK).
