On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek <ja...@redhat.com> wrote: > 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 I understand it correctly, the reason Google doesn't want libgcc_s.so is Google believes GPLv3 exception only applies to libgcc,a and libgcc_eh,a, not libgcc_s.so. If GPLv3 exception also applies to libgcc_s.so, Google may consider using libgcc_s.so. -- H.J.
