From: Joseph Myers <joseph@codesourcery.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Rafal Luzynski <digitalfreak@lingonborough.com>,
<libc-alpha@sourceware.org>, "Dmitry V. Levin" <ldv@altlinux.org>,
Carlos O'Donell <carlos@redhat.com>
Subject: Re: glibc 2.27: 3 weeks till release
Date: Thu, 18 Jan 2018 13:31:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1801181325350.2753@digraph.polyomino.org.uk> (raw)
In-Reply-To: <62c67b94-2e3e-c0b8-1b00-d195354d4d2b@redhat.com>
On Thu, 18 Jan 2018, Florian Weimer wrote:
> Yes, the final part is the typical problem. I have thought about this some
> more and I don't think we need to preserve static binary compatibility at this
> point. In the future, when we improve static linking in general, we should
> consider relaxing the consistency checks and perhaps change the way we add new
> locale data to accommodate existing binaries.
Improving static binary compatibility would also mean ensuring the things
that load .so modules work reliably even when the installed .so modules
are from a newer libc version. That's NSS, and character set conversions
loading gconv modules, at least.
Is ld.so.cache compatibility between different glibc versions ever a
consideration? I decided not, when reviewing the RISC-V patches (i.e.,
there was no need to ask for 32-bit and 64-bit libraries to be identified
separately in the cache now, even though that would be needed if in future
Linux supports RV32I binaries on RV64I systems, because it would be OK to
change the flag values incompatibly at that future point).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2018-01-18 13:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-11 3:44 Dmitry V. Levin
2018-01-11 5:10 ` Carlos O'Donell
2018-01-11 13:45 ` Joseph Myers
2018-01-11 14:42 ` Zack Weinberg
2018-01-11 14:46 ` Dmitry V. Levin
2018-01-11 14:51 ` Zack Weinberg
2018-01-11 14:57 ` Dmitry V. Levin
2018-01-11 15:14 ` Zack Weinberg
2018-01-11 16:03 ` Rafal Luzynski
2018-01-12 4:15 ` Carlos O'Donell
2018-01-12 7:47 ` Florian Weimer
2018-01-12 8:10 ` Rafal Luzynski
2018-01-12 17:15 ` Joseph Myers
2018-01-22 23:58 ` Rafal Luzynski
2018-01-23 20:23 ` Carlos O'Donell
2018-01-23 21:57 ` Rafal Luzynski
2018-01-17 22:38 ` Carlos O'Donell
2018-01-18 11:21 ` Florian Weimer
2018-01-18 11:59 ` Rafal Luzynski
2018-01-18 12:28 ` Florian Weimer
2018-01-18 13:31 ` Joseph Myers [this message]
2018-01-18 13:34 ` Florian Weimer
2018-01-12 4:19 ` Carlos O'Donell
2018-01-12 12:54 ` Adhemerval Zanella
2018-01-18 15:30 ` Dmitry V. Levin
2018-01-18 16:42 ` Adhemerval Zanella
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=alpine.DEB.2.20.1801181325350.2753@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=carlos@redhat.com \
--cc=digitalfreak@lingonborough.com \
--cc=fweimer@redhat.com \
--cc=ldv@altlinux.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).