The following reply was made to PR pkg/40954; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: Christopher Richards <richards%CS.Princeton.EDU@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: pkg/40954: lang/smlnj broken with 64-bit time_t
Date: Sat, 19 Sep 2009 09:24:43 +0000
On Wed, Mar 11, 2009 at 10:35:01PM +0000, Christopher Richards wrote:
> The attached patch solves the lang/smlnj build failure under 64-bit
> time_t, by way of updating the package from version 110.42 (vintage
> 2002) to 110.69, the most recent "working" version. In SML/NJ
> parlance, the "working" version is the stable release, and the
> "stable" version is the haunted-mansion, nobody-goes-there release. I
> could not begin to summarize the six years of changes this update
> entails.
>
> This new version survives the build and appears to function correctly
> (as tested on NetBSD/xen, -current as of 2009-03-06), but the runtime
> still assumes a 32-bit time_t, and will still lose beginning in 2038.
So I finally got around to trying it (sorry it took so long...) and it
builds and installs ok, given the modernization of removing @dirrm
from the PLIST.
But, it breaks lang/twelf. The compile thereof gives
src/timing/timing.sml:83.26-84.38 Error: operator and operand don't
agree [tycon mismatch]
operator domain: {gc:Time.time, sys:Time.time, usr:Time.time} *
{gc:Time.time, sys:Time.time, usr:Time.time}
operand: {gc:Time.time, sys:Time.time, usr:Time.time} *
{sys:Time.time, usr:Time.time}
in expression:
plus (CPUTime,evalCPUTime)
val it = false : bool
stdIn:6.45-6.58 Error: unbound structure: Server in path Server.server
The build doesn't stop, but twelf-server doesn't get (fully?)
installed, resulting in this behavior at runtime:
/usr/pkg/bin/sml: Fatal error -- unable to open heap image
"/usr/pkg/lib/twelf/bin/.heap/twelf-server"
Config.read sources.cfg
Process twelf-server exited abnormally with code 1
Do you know how to go about fixing this? Since twelf is the only thing
in pkgsrc that uses smlnj, I'm a bit reluctant to commit the update
without fixing it as well.
(It would also be nice sometime to set up a proper buildlink3 for
smlnj instead of using a Makefile.common, but that's not entirely
trivial and not really a priority.)
--
David A. Holland
dholland%netbsd.org@localhost