> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Sam James: > >> In Gentoo, we've been planning out what we should do for time64 on >> glibc [0] and concluded that we need some support in glibc for a newer >> option. I'll outline why below. >> >> Proposal: glibc gains two new build-time configure options: >> * --enable-hard-time64 >> * --enable-hard-lfs > > We should define new target triplets for this if it's really required. I hadn't considered that option. I'll reflect on it. Please let me know if you have further thoughts on this. But that said, these binaries are broken anyway in 2038? > We need to support legacy binaries on i386. Few libraries are > explicitly dual-ABI. Whether it's safe to switch libraries above glibc > to LFS or time64 needs to be evaluated on a per-library basis. For most > distributions, no one is going to do that work, and we have to stick to > whathever we are building today. While I agree, I don't think it's as well-known that it should be that these are ABI breaking and require inspection. It's being done ad-hoc or in many cases, not at all. Part of the use of this thread is, if nothing else, we can show upstreams and other distros It if they're confused. It's very easy to miss that a package has started enabling LFS and then your opportunity to catch the ABI breakage is gone. It doesn't help that I (and I suspect most distribution maintainers) do all development on x86_64 and hence even ABI diffing isn't going to notice. You have to specifically diff the build system, which I do, but it's not easy if it's buried deep within gnulib or something. > >> These would hard-enable the relevant #defines within glibc's headers >> and ensure that any binaries built with such a glibc have both Large >> File Support (LFS) and time64 support. >> >> I've come to the conclusion it's infeasible to try handle the >> migration piecemeal. Various mismatches can and will occur (and while >> it's more likely with time64, it's possible with LFS too) [1]. >> >> We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes >> of note [2][3] >> 1. addition of a new AC_SYS_YEAR2038 macro; >> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038. >> >> Indeed, the gnulib version of change #2 is exactly how we ended up with >> wget/gnutls breaking [1]. I feel this shows that the only approach >> "supported" by glibc right now is untenable. > > AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive > for Fedora unfortunately. > > I thought the gnulib change has been reverted? > > I really wish the rest of GNU would talk to glibc maintainers before > overriding glibc maintainer decisions. If we cannot revert this in > autoconf (and gnulib), this will very much endanger the Fedora i386 > port. Debian will probably be impacted in the same way. > Right, we need to be unified on this, because it's confusing enough without unilateralism.
Attachment:
signature.asc
Description: Message signed with OpenPGP
