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

[Ilias Tsitsimpis]

On Tue, Apr 09, 2024 at 08:53PM, Adrian Bunk wrote:
> On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote:
> > 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.

Aha! Didn't know that, thanks for flagging this. I am surprised that we
hadn't noticed this earlier (as we see now, GHC is completely broken).

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

Hmm true. My guess here is that GHC gets a completely bogus CTime value
back from clock_gettime() (we proved that the way we call
clock_gettime() is currently broken) and when it passes this CTime value
to localtime_r() it fails. I haven't verified any of this, just a guess.

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

Thank you! Can we maybe run this against all Haskell libraries and
identify the ones that are currently broken? Maybe we have such a script
already for the time64 transition.

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

I believe it returns the timezone in seconds (i.e., 3600 for +1 hour
timezone), so CLong should be large enough to hold this value. My guess
right now is that it fails due to the bogus CTime value that we pass, we
need to test this.

-- 
Ilias