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

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

[Florian Weimer]

We have:

define build-shlib-helper
$(LINK.o) -shared -static-libgcc -Wl,-O1 $(sysdep-LDFLAGS) \
	  $(if $($(@F)-no-z-defs)$(no-z-defs),,-Wl,-z,defs) $(rtld-LDFLAGS) \
	  $(extra-B-$(@F:lib%.so=%).so) -B$(csu-objpfx) \
	  $(extra-B-$(@F:lib%.so=%).so) $(load-map-file) \
	  -Wl,-soname=lib$(libprefix)$(@F:lib%.so=%).so$($(@F)-version) \
	  $(LDFLAGS.so) $(LDFLAGS-lib.so) $(LDFLAGS-$(@F:lib%.so=%).so) \
	  -L$(subst :, -L,$(rpath-link)) -Wl,-rpath-link=$(rpath-link)
endef

And:

define build-module-helper
$(LINK.o) -shared -static-libgcc $(sysdep-LDFLAGS) $(rtld-LDFLAGS) \
	  $(if $($(@F)-no-z-defs)$(no-z-defs),,-Wl,-z,defs) \
	  -B$(csu-objpfx) $(load-map-file) \
	  $(LDFLAGS.so) $(LDFLAGS-$(@F:%.so=%).so) \
	  -L$(subst :, -L,$(rpath-link)) -Wl,-rpath-link=$(rpath-link)
endef

Why do we use -static-libgcc?  Doesn't this invalidate some of our
tests, because users do not generally build with -static-libgcc?

Background:

I'm dealing with an issue caused by a symbol reference from libgcc_eh.a
to ld.so.  We do not link test modules against a libc.so linker script,
instead we use:

link-libc-args = -Wl,--start-group \
		 $(libc-for-link) \
		 $(common-objpfx)libc_nonshared.a \
		 -Wl,--as-needed $(elf-objpfx)ld.so -Wl,--no-as-needed \
		 -Wl,--end-group

I believe this is the reason why libgcc_eh.a can't reference ld.so: The
initial ld.so gets droped due to --as-needed, and the -lc after
libgcc_eh.a does not supply a second copy because it ends up linking
against the in-tree libc.so, which just the ELF object.

Dropping -static-libgcc seems to make this work.

An alternative would be to use a libc.so linker script during the glibc
as build (not just after installtion).  This should bring back the ld.so
reference with -lc after libgcc_eh.a.

Thanks,
Florian

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

[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) (note that this requires appropriate use of 
--with-glibc-version when configuring that first GCC in some cases - and 
that, while I verified the "identical stripped binaries" property when 
implementing --with-glibc-version and related glibc build fixes, I haven't 
checked it recently and it's possible it could have regressed since 2013).

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).

Testing is not expected to work fully with a static-only C-only 
inhibit_libc GCC, so using the real shared libgcc in linking tests should 
be OK (and desirable when the tests correspond to normal user code that 
would end up linking with shared libgcc, on the general principle of 
testing something as close as possible to how people would use installed 
glibc).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 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

Re: 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
> 

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

[Joseph Myers]

On Mon, 10 Jan 2022, Florian Weimer via Libc-alpha wrote:

> Do we really need to support building the test suite against a
> static-only GCC build?

I don't think that's ever worked properly.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Florian Weimer]

* Joseph Myers:

> On Mon, 10 Jan 2022, Florian Weimer via Libc-alpha wrote:
>
>> Do we really need to support building the test suite against a
>> static-only GCC build?
>
> I don't think that's ever worked properly.

Then I think not using -static-libgcc plus a check that installed
objects do not depend on libgcc_s seems strictly superior than using
-static-libgcc: this way, we ensure that we do not pull in libgcc bits
we do not expect to have in glibc (like the unwinder).

Thanks,
Florian