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?
