[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On time64 and Large File Support
From: |
Florian Weimer |
Subject: |
Re: On time64 and Large File Support |
Date: |
Fri, 11 Nov 2022 12:38:41 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
* Sam James:
>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@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
- Re: On time64 and Large File Support, Sam James, 2022/11/11
- Re: On time64 and Large File Support,
Florian Weimer <=
- Re: On time64 and Large File Support, Zack Weinberg, 2022/11/11
- Re: On time64 and Large File Support, Sam James, 2022/11/11
- Re: On time64 and Large File Support, Zack Weinberg, 2022/11/12
- Re: On time64 and Large File Support, Paul Eggert, 2022/11/12
- Re: On time64 and Large File Support, Bruno Haible, 2022/11/12
- Re: On time64 and Large File Support, Paul Eggert, 2022/11/12
- Re: On time64 and Large File Support, Wookey, 2022/11/12
- Re: On time64 and Large File Support, Paul Eggert, 2022/11/12
- Re: On time64 and Large File Support, Sam James, 2022/11/15