From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
Subject: Re: Why -static-libgcc? (Or: Do we need a build-time libc.so linker script?)
Date: Mon, 10 Jan 2022 10:26:54 -0300 [thread overview]
Message-ID: <d0e8b82e-ec63-3828-75cb-a80115ec5c8d@linaro.org> (raw)
In-Reply-To: <87v8yrycco.fsf@oldenburg.str.redhat.com>
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
>
next prev parent reply other threads:[~2022-01-10 13:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 22:16 Florian Weimer
2021-11-24 23:19 ` Joseph Myers
2022-01-10 13:00 ` Florian Weimer
2022-01-10 13:26 ` Adhemerval Zanella [this message]
2022-01-11 0:58 ` Joseph Myers
2022-04-19 11:57 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0e8b82e-ec63-3828-75cb-a80115ec5c8d@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).