On Wed, Mar 07, 2012 at 06:24:14PM -0800, Ollie Wild wrote:
> For reasons outside the scope of this discussion, we're experimenting
> with statically linking libgcc.a and libgcc_eh.a into dynamically
> linked applications which depend on libc but no other dynamic
> libraries. To make this work, libc needs to access a few functions
> for stack unwinding inside pthread_cancel. With suitable
> modifications, everything works, except for one problem: libgcc_eh.a
> is compiled with -fvisibility=hidden.
The reason why libgcc.a symbols are hidden is to avoid exporting those
symbols from shared libraries for -static-libgcc etc. links.
It used to cause big troubles, the symbols were e.g. exported from one
shared library as implementation detail, and other shared libraries that
needed the same symbols relied on those symbols exported from them, but
if you slightly change the implementation of the shared library, the libgcc
symbol might not be needed any longer, thus no longer exported, and suddenly
the other shared libraries break, because they can't find their definitions.
libgcc routines are usually short (dfp is an exception, but those really
don't belong into libgcc), so duplicating them doesn't matter much
and there is always -shared-libgcc.
The reason why libgcc_eh.a is split from libgcc.a is that the unwinder
really should be just one in the whole process, especially when one had to
register shared libraries/binaries with the unwinder it was very important.
So, libgcc_eh.a is meant for -static linking only, where you really can't
link libgcc_s.so.1, for all other uses of the unwinder you really should
link the shared libgcc_s.so.1 instead. Note e.g. glibc internally dlopens
libgcc_s.so.1.
> If no one knows a valid reason for this, I'll submit a patch to remove
> it from trunk.
Please don't.
Jakub
