Why -static-libgcc? (Or: Do we need a build-time libc.so linker script?)

[Adhemerval Zanella]

On 10/01/2022 10:00, Florian Weimer via Libc-alpha wrote:
> * Joseph Myers:
> 
>> On Wed, 24 Nov 2021, Florian Weimer via Libc-alpha wrote:
>>
>>> Why do we use -static-libgcc?  Doesn't this invalidate some of our
>>> tests, because users do not generally build with -static-libgcc?
>>
>> There is a principle that (a) building glibc should not require a GCC 
>> built with shared libgcc (to avoid circular dependencies, because building 
>> shared libgcc requires having first built shared libc) and (b) if you 
>> build glibc with a static-only C-only inhibit_libc GCC, the resulting 
>> stripped binaries should be identical to those you get from a longer 
>> alternating sequence of GCC and glibc builds (in particular, the binaries 
>> should be identical to those you get from building with shared libgcc 
>> available)
> 
> I agree that this is a useful goal.
> 
>> So building installed shared libraries needs to avoid any dependence on 
>> shared libgcc (unless such dependence is handled in a way not requiring 
>> shared libgcc to be available at build time - note that we know the 
>> libgcc_s SONAME via shlib-versions, so if desired we could insert a 
>> DT_NEEDED for it without using the real library, by building a dummy 
>> shared library to link against or otherwise).
> 
> I think we could still build without -static-libgcc and check that the
> installed shared objects do not contain a DT_NEEDED references to
> libgcc_s.  But it will not fix the test linking issue I encountered
> (libgcc_eh.a references not resolvable against ld.so because of
> --as-needed and link order).
> 
> Do we really need to support building the test suite against a
> static-only GCC build?

I am not sure it makes sense since we do require a libgcc_s.so to have
the cancellation and stack unwinding to work.

> 
> This is not an urgent issue because direct symbol access to ld.so is
> incompatible with static dlopen because it the inner namespace binds to
> the uninitialized copy of ld.so, so things like __tls_get_addr do not
> work.  For some application scenarios, this is probably okay, but for
> parts of libgcc_s (libgcc_eh.a especially), not so much.
> 
> Thanks,
> Florian
>