Hi Adrian,
On Tue, Apr 09, 2024 at 12:56PM, Adrian Bunk wrote:
> FTR, in haskell-hourglass this is #1001686 which already failed on x32
> for this reason.
I believe it's not. haskell-hourglass used to work on arm{el,hf} just
before the time64 transition.
> My reading of the code is that this happens when
> libraries/time/lib/cbits/HsTime.c returns 0x80000000 due to
> localtime_r() called in this function returning an error.
>
> The "localtime_r failed" is from
> libraries/time/lib/Data/Time/LocalTime/Internal/TimeZone.hs
The problem is that GHC uses the ccall calling convention in order to
call clock_gettime() [1]. GHC assumes time_t to be 64-bits, but ends up
calling the old 32-bits variant of clock_gettime(), and not the new one
__clock_gettime64().
Here is more information about GHC's FFI calling conventions[2].
Here is also an upstream issue about this[3].
[1]
https://gitlab.haskell.org/ghc/packages/time/-/blob/baab563ee2ce547f7b7f7e7069ed09db2d406941/lib/Data/Time/Clock/Internal/CTimespec.hsc#L30
[2] https://www.haskell.org/ghc/blog/20210709-capi-usage.html
[3] https://github.com/haskell/directory/pull/145
The fix here is to backport (at least) the following patches which
change these calls to use the capi calling convention:
*
https://gitlab.haskell.org/ghc/packages/time/-/commit/d52314edb138b6ecd7e888c588f83917b0ee2c29
*
https://gitlab.haskell.org/ghc/packages/directory/-/commit/f6b288bd96fba5a955d1f73663eb52c1859ee765
Other Haskell libraries may have the same bug as GHC if they are calling
directly the C functions using the ccall calling convention. An example
is haskell-hourglass, which needs to be patched as well:
*
https://github.com/vincenthz/hs-hourglass/blob/36bd2e6d5d0eb316532f13285d1c533d6da297ef/Data/Hourglass/Internal/Unix.hs#L82
We need a way to identify every package that is broken.
--
Ilias
