[jjhelmus]

Statically link libgcc_s in Linux distributions so they can be run without this library on the host system. This also avoid issue if the GCC install in the LLVM bundled is accidentally linked.

[jjhelmus]

This approach allows the use of the GCC headers and libraries included in the llvm bundle. These are build against a sysroot with an older glibc and therefore do not container newer symbols.

Another option is to link against gcc runtime files within the sysroot.

[indygreg]

Please do due diligence on this before shipping. I want to say that statically linking this library is dangerous for similar reasons as statically linking glibc. But I may be crossing wires in my head.

[nazeeh111]

I checked the GCC linker guidance and found one concrete compatibility question to close before relying on this change.

[nazeeh111]

GCC documents -static-libgcc as requiring care when C++ exceptions can cross shared-library boundaries: in that case, the application and libraries should use shared libgcc (https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html). These distributions load native extension modules, so could you clarify whether cross-DSO C++ exception propagation is outside the supported extension ABI, and add a targeted compatibility test or document that boundary? The JIT patch appears to address registering generated Python frames with glibc's shared unwinder; I don't see a test for C++ exception propagation across libpython and extension DSOs. Prepared with Codex assistance; this is a documentation-based compatibility question, not a reproduced failure.

[jjhelmus]

libgcc_s is used for two cases in this project: to provide helper functions for type conversions that the architecture/libc does not handle itself and in Python 3.15+ for registration of frames when the JIT is enabled.

The later is a case where libgcc_s should not be statically linked as the static implementation may register frames separate from the unwinder that glibc loads when executing a backtrace(). This could result in JIT frames registered with one copy not being visible to the other or being corrupt. Keeping libgcc_s dynamically linked avoids this.

The helpers function are safe to statically link but given that libgcc_s is needed this does not need to be done in most cases. Helper function that are newer than the libgcc_s minimum supported version should be statically linked. This is what #1391 does, it pulls the half-float helper function used in CPython 3.16 in early so that they are statically linked from libgcc.a.

[jjhelmus]

Closing in favor of #1391