http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
Bug ID: 60428 Summary: non-exception (e.g. C) ARM Linux programs depend on libgcc_s Product: gcc Version: 4.5.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se When compiling a C program for ARM Linux, you can easily end up with dependencies on libgcc_s. This is very annoying as it is not how other targets behave and it means extra work to make binaries that work on a lot of system. I tried to understand the issue, and from what I gather the ARM EABI has a more advanced stack unwinding system that involves calling functions. This combined with helpers in libgcc.a for U64 division that can throw exceptions, results in a dependency on libgcc_s. First question: Why are these libgcc.a functions being built with unwind tables? The stated reason is because of CPU exceptions, but AFAIK those result in signals, not language level exceptions? Second question: Let's assume libgcc.a truly needs the unwinding, or if nothing else there will be other C code that is compiled with -fexceptions for compatibility; can we remove the hard NEEDED for libgcc_s and only use it if some C++ (or similar) code pulls it in? I think the answer to the second question is yes. We've applied the attached patch to our gcc and it seems to do the trick. C code will not have libgcc_s as NEEDED, yet you can still throw exceptions just fine, even across C code compiled with -fexceptions. I am a bit concerned about the interaction of weak symbols in a static library (libgcc.a) and versioned symbols in a "proper" library (libgcc_s.so). Comments?