Did I mention that #Gentoo has now #time64 stages for #x86?

Well, we have #Docker images now as well:

$ docker run gentoo/stage3:i686-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t
$ docker run gentoo/stage3:i686-ssemath-t64-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
2335219200.0

(there's only a "ssemath" variant, using "-mfpmath=sse" — the floating-point computations are done on 64-bit SSE registers rather than 80-bit x87 registers, giving more consistent results between 32-bit x86 and everything else)

A wspominałem, że mamy już w #Gentoo archiwa stage3 w wariancie #time64 dla #x86?

No to wspominam, że teraz mamy też obrazy Dockera:

$ docker run gentoo/stage3:i686-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t
$ docker run gentoo/stage3:i686-ssemath-t64-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
2335219200.0

(robimy tylko wariant "ssemath", czyli z "-mfpmath=sse" — operacje zmiennoprzecinkowe wykonywane są przy pomocy 64-bitowych rejestrów SSE, a nie 80-bitowych x87, co daje mniejsze rozbieżności między 32-bitowych x86, a całą resztą architektur)

#Docker

Najnowsze wersje (rewizje) #Clang 18, 19 i 20 w #Gentoo obsługują teraz nowe krotki #time64. To jest, można dać:

clang --target=i686-pc-linux-gnut64

i dostanie się z automatu `-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64`. A co ważniejsze — clang 19+ zacznie działać na systemach z takim CHOST-em.

Istnieje jednak pewne ryzyko, że zmiany zostaną cofnięte, bo można postrzegać je jako zmianę ABI, jak zauważył to projekt #Zig (aczkolwiek oni zdecydowali się przestać polegać na pełnym dopasowaniu wszystkich wartości enumeracji).

https://discourse.llvm.org/t/potential-abi-break-in-19-1-3/82865

Teraz tylko ktoś musi zająć się zmianami po stronie GCC.

#LLVM

The latest versions (revisions) of #Clang 18, 19 and 20 in #Gentoo now support the new #time64 tuples. That is, if you run e.g.:

clang --target=i686-pc-linux-gnut64

you're going to get `-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64` automatically. But more importantly, clang 19+ will no longer refuse to run on systems with CHOST set to that value.

That said, there's some risk that the change may be reverted because it's debatably an ABI break, as noticed by #Zig (but they've decided to update their code not to rely on matching all enum values).

https://discourse.llvm.org/t/potential-abi-break-in-19-1-3/82865

Now someone finally needs to handle GCC.

#LLVM

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t