This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why are libgcc.a and libgcc_eh.a compiled with -fvisibility=hidden?

On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek <> 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, for all other uses of the unwinder you really should
> link the shared instead. ?Note e.g. glibc internally dlopens

If I understand it correctly, the reason Google doesn't want
is Google believes GPLv3 exception only applies to libgcc,a and libgcc_eh,a,
not  If GPLv3 exception also applies to, Google
may consider using


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]