From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Florian Weimer <fweimer@redhat.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader)
Date: Wed, 8 Dec 2021 22:29:01 +0530 [thread overview]
Message-ID: <026b3d7a-7de3-3f7e-d59e-85fe7514eb54@gotplt.org> (raw)
In-Reply-To: <87h7bjmnt0.fsf@oldenburg.str.redhat.com>
On 12/8/21 15:16, Florian Weimer via Libc-alpha wrote:
> The glibc 2.34 release really should have added a GLIBC_2.34
> symbol to the dynamic loader. With it, we could move functions such
> as dlopen or pthread_key_create that work on process-global state
> into the dynamic loader (once we have fixed a longstanding issue
> with static linking). Without the GLIBC_2.34 symbol, yet another
> new symbol version would be needed because old glibc will fail to
> load binaries due to the missing symbol version in ld.so that newly
> linked programs will require.
>
> This needs to be backported to the glibc 2.34 release branch as well,
> where hopefully all distributions will pick it up eventually.
ISTM we could move symbols between ld.so and libc.so at will, without
bumping symbol versions because they'll always be used together. In
that sense, maybe we should not really consider such moves as ABI events
at all?
Siddhesh
next prev parent reply other threads:[~2021-12-08 16:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-08 9:46 Florian Weimer
2021-12-08 9:56 ` Andreas Schwab
2021-12-08 10:06 ` Florian Weimer
2021-12-08 10:20 ` Andreas Schwab
2021-12-08 10:28 ` Florian Weimer
2021-12-08 14:06 ` H.J. Lu
2021-12-24 19:01 ` Florian Weimer
2022-01-13 17:22 ` Carlos O'Donell
2022-01-13 17:32 ` Florian Weimer
2021-12-08 16:59 ` Siddhesh Poyarekar [this message]
2021-12-13 12:15 ` Florian Weimer
2021-12-13 14:54 ` Siddhesh Poyarekar
2022-01-13 17:56 ` Carlos O'Donell
2022-01-13 18:00 ` Carlos O'Donell
2022-01-22 16:08 ` H.J. Lu
2022-01-24 14:31 ` 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=026b3d7a-7de3-3f7e-d59e-85fe7514eb54@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=fweimer@redhat.com \
--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).