This is the mail archive of the
mailing list for the GCC project.
Re: Why are libgcc.a and libgcc_eh.a compiled with -fvisibility=hidden?
On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek <email@example.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
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.