[ 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@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@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@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@GLIBC_2.4
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so
U utimensat@GLIBC_2.6
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so
U utimensat@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
