Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition

[Ilias Tsitsimpis]

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