* Sam James: >> On 11 Nov 2022, at 09:19, Florian Weimer <fwei...@redhat.com> 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?
No, I expect users to run them in time-shifted VMs or containers. Wrong dates are better than no ability to run anything at all. And whoever can recompile to switch to time64 can just recompile for a 64-bit target. There are some embedded users that stick to 32-bit for cost savings, but I think the cost allocation is quite wrong: They save a bit on per-unit costs, but they do not really contribute back to GNU (and most don't even use glibc, although there is some use out there). >> 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. I really assumed that setting the default in glibc would solve this for everyone: binary distributions keep using time32, and source-based embedded distributions can switch to time64 if they want to. *sigh* I mean, we have things like more compact stack usage through certain ABI-breaking GCC options. The kernel can use those safely, but few people attempt to apply them to userspace. There, having the right default in the toolchain is sufficient. I didn't expect time64 to be different. Thanks, Florian
