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

[Adrian Bunk]

[ Steve added, for the symbol list question ]

On Tue, Apr 09, 2024 at 09:44:43PM +0300, Ilias Tsitsimpis wrote:
> 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).

I wouldn't call it "completely broken".

I'm too lazy to get exact numbers, but the arm{el,hf} situation is more 
like 1000 packages built (a large part with tests) and 10 failed.

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

Steve, do you have a list of all bad symbols for the time_t transition?

With this list it should be possible to just install all currently 
installable Haskell packages on a porterbox and do something like

$ for s in gettimeofday utimensat localtime localtime_r; do for f in /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/*.so /usr/lib/haskell-packages/ghc/lib/arm-linux-ghc-9.4.7/*.so; do nm -D $f | grep $s@ && echo $f; done; done
         U gettimeofday at GLIBC_2.4
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so
         U utimensat at GLIBC_2.6
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so
         U utimensat at GLIBC_2.6
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSunix-2.7.3-ghc9.4.7.so
$

That last one is likely
libraries/unix/System/Posix/Files/Common.hsc:foreign import ccall unsafe "utimensat"

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

Yes, I suspect that this function with
  CTime -> Ptr CInt -> Ptr CString -> IO CLong
gets called as
  CLong -> Ptr CInt -> Ptr CString -> IO CLong
but I'm surprised if Haskell does not catch something like that at 
compile time.

> Ilias

cu
Adrian