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

[Florian Weimer]

* 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?

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