On Fri, May 25, 2001 at 04:45:33PM +0200, Raymond Wiker wrote:
> I've made a couple of half-hearted attempts at compiling SBCL
> under FreeBSD. At the moment it seems that I'm running into trouble
> because FreeBSD (and OpenBSD, and possibly also NetBSD) have 64-bit
> values in struct stat, and 64-bit integers are not handled by the FFI
> code. (Unix.lisp and fd-streams.lisp have a feature-test on :openbsd
> related to this; I think this test should be changed to :bsd instead.)
> The "old" version of unix.lisp had the 64-bit values split
> into two 32-bit parts. The current version of SBCL uses a wrapper for
> stat(), which allows us to use the same structure definition for all
> Would it be an idea to make the wrapper code (and struct
> definition) use two 32-bit values each for file size and block count?
> For Linux, the most significant word would "always" be zero (or at
> least until Linux gains support for file sizes > 2^32 bytes).
> The alternatives would be to just use the least significant 32
> bits of the file size, or to delay work on this until the FFI is
> updated to support 64 bits.
The first alternative is what I did in 0.6.12.12:
typedef u32 ffi_off_t; /* since OpenBSD 2.8 st_size is 64 bits */
Eventually, of course, it should be upgraded to support 64 bits
properly. I haven't looking into how hard it would be to fix the FFI
to do this. If it's easy, then the FFI should be fixed; otherwise,
doing the two-32-bit-fields workaround by hand could be enough for at
least a year or two.
I no longer have any FreeBSD machines, but I've spent quite a lot of
time trying to get the OpenBSD port to work, with no success so far.
(The system builds -- emitting an error message after writing
sbcl.core, but sbcl.core is still runnable -- and runs a little bit,
but it dies fairly early in "cd tests ; sh run-tests.sh" with GC-related
or memory-corruption-related problems.) A number of annoying problems
have come together to impede progress on this:
* Something about the way the GC fails sometimes tickles a
bug in OpenBSD, causing a kernel panic or system hang.
* The X11 driver for my Toshiba Satellite 2800 works OK unless I
try to switch back to a virtual console, at which point it is
likely to leave the display so messed up I need to powercycle the
machine. And OpenBSD's panic output is on one of the virtual
* The simplest symptom of the OpenBSD problems is the
fatal error encountered in SBCL runtime system:
GC invariant lost, file "gencgc.c", line 513
error which which occurs after writing sbcl.core at the end of
warm init. How hard can it be to figure out where this is
coming from? Pretty hard, it turns out. I haven't been able to
figure out why this would be emitted after the fclose() at
the end of save(), since the code is after all pretty simple
and there's no 'atexit' stuff anywhere in the system. Maybe
there's just some weird stream-buffering stuff that makes
it appear out of order, although I've added enough diagnostic
output on stderr that that seems unlikely. It should be a
no-brainer to use gdb "break lose" to find out, except that the
OpenBSD gdb signal-handling problems that I just posted about
on cmucl-imp@... have so far kept that from working.
Meanwhile, 0.6.12.1 is still working fine on the same machine (and
getting lots of use since this is now my fastest machine). I've spent
several hours, in several different sessions, going over diffs and
trying to guess what could be causing the problem, with no success.
Very frustrating. So if you happen to figure out the problem on
FreeBSD and it happens to solve the OpenBSD problems too, I'll be very
William Harold Newman <william.newman@...>
"Incrementally extended heuristic algorithms tend inexorably toward the
incomprehensible." -- http://www.unlambda.com/~james/lambda/lambda.txt
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C