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

[Adrian Bunk]

On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote:
> Hi Adrian,

Hi Ilias,

> 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.

before this transition x32 was the only 32bit architecture with 64bit time_t.

> > 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 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

This localtime_r issue I mentioned is not covered in the above commit in 
time.

>...
> We need a way to identify every package that is broken.

$ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | grep gettimeofday
         U gettimeofday at GLIBC_2.4
...

$ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so | grep utimensat                             
...
         U utimensat at GLIBC_2.6

$ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | grep localtime
         U __localtime64_r at GLIBC_2.34


But the last one is the broken localtime_r one, is anything going wrong 
with the ccall from TimeZone.hs to cbits there?

get_current_timezone_seconds() returning long is wrong,
and might contribute to that bug:

  foreign import ccall unsafe "HsTime.h get_current_timezone_seconds"
    get_current_timezone_seconds ::
        CTime -> Ptr CInt -> Ptr CString -> IO CLong
...
  getTimeZoneCTime ctime =
...
                    secs <- get_current_timezone_seconds ctime pdst pcname

I don't know Haskell, but is this declaring ctime as CLong,
and then passing it instead of a CTime?


> Ilias

cu
Adrian