Re: [Y2038] debian/armhf time64 build?
On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
> On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
>> On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
>>...
>> > I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
>> > use musl-1.2, not glibc, and they have a much smaller set of packages.
>>
>> OK. We still have plenty of bugs to find then :-)
>
> Such bugs have already been found, reported and fixed in Debian for
> 10 years thanks to the x32 port (e.g. #700012).
>
> More than 13k packages are currently Installed on x32 after having been
> natively built and (if they have) passing their build time tests.
There is a minimal user base on x32, so I'm sure a lot of bugs
have gone unnoticed. Having 64-bit time_t on BSD and Windows
probably did more to find bugs, but there are still lots of
issues where neither of this would help. For instance:
- Any applications that use direct system calls with a 32-bit
time_t have to change to the correct replacement syscall.
This never had to be done on x32, because there is only one
such set of syscalls. A number of upstream packages already
got fixed for riscv32, but unfortunately some of those were
done in a way that is still broken for architectures that
have both the time32 and time64 versions.
Most commonly, this affects __NR_futex/SYS_futex, but there
are other syscalls needed elsewhere
- Libraries using input_event structures on /dev/input/*
need to have an updated copy of the kernel headers. Most
upstream packages do now, but I'm sure there are some left.
- Packages that rely on seccomp have to be updated to
allow both the old and new versions of system calls in their
whitelists
- Anything that is written in a language other than C but
links to C libraries needs to be updated to use the new
data structure definitions. Some of these may have a special
case for x32, or they are just wrong. There are a lot of
python or rust libraries affected by this, and no obvious
answer.
- Things that are written in a language other than C/C++
but don't link to C libraries should keep working, but
will not be y2038 safe unless they also migrate to the
time64 interfaces by copying what glibc did.
- Any package that currently relies on having a 32-bit
off_t/ino_t will break after being forced to update to
the 64-bit version, even if they don't care about
time_t.
- Packages may hardcode the time_t/timeval/timespec
definition. If they use __kernel_long_t, they would
even work on x32, but break on any other 32-bit ABI.
Arnd
Reply to: