This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.27: 3 weeks till release
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