[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Y2038] debian/armhf time64 build?

On 2022-10-02 16:23 +0200, Arnd Bergmann wrote:
> On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
> >
> > 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:

OK, rather later than planned, I have done a bootstrap of the bottom
154 debian packages (as of Jan 17th) i.e the set you get from here:
(thanks to Helmut for the marvellous rebootstap making this mostly painless)

'armhf': standard armhf,
'lfs'  : armhf+ DEB_BUILD_OPTIONS=future+lfs
'tt'   : armhf+ -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 DEB_BUILD_OPTIONS=future+lfs

I'm trying to dump some ABI differences to see what _actually_ changes,
but I've also just been randomly installing random tt packages in an
armhf chroot to see what broke.

'nothing obvious' is my initial impression so far, so I'd welcome any
suggestions for things which are easy to test that we might expect to
break. (e.g translating the things below into commands I could type to check?)

Suggestions for things further up the package stack will also be useful for the future.

The packages for lfs and tt are in these repos:

It's entirely possible that build flags have been ignored in places
and some of these packages are not actually as advertised/intended -
I'm still checking that.

> - 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
Principal hats:  Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: