Hello! Thanks for finding a typo. Here is a new patch (diff from https://github.com/sbcl/sbcl/commit/4c0c126812cb113c2be522386bd93453c6317918) tested with DragonFly 3.8 x86-64. Unfortunately, I do not have x86 machine by now to test on that architecture. Test results (hand typed ;): Finished running tests. Status: Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Expected failure: walk.impure.lisp / (WALK-LET* HAIRY-SPECIALS) Expected failure: walk.impure.lisp / (WALK-LET* HAIRY-SPECIALS) (51 tests skipped for this combination of platform and features) ok //apparent success (reached end of run-tests.sh normally) Tue Jun 17 19:42:15 MSK 2014 Please, do not worry that #define CREATE_POST_MORTEM_THREAD was removed, it is useless anyway. As for threads, I have no idea, what to do. SBCL can be compiled with sb-thread on x86-64, but it will randomly crash while using this functionality. I have this in GDB: gdb ../src/runtime/sbcl sbcl.core GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-dragonfly". For bug reporting instructions, please see: ... Reading symbols from /home/vasily/sbcl-dragonfly/src/runtime/sbcl...done. BFD: Warning: /home/vasily/sbcl-dragonfly/tests/sbcl.core is truncated: expected core file size >= 1072648192, found: 152567808. [New process 168] [New process 172] Core was generated by `sbcl'. Program terminated with signal 4, Illegal instruction. #0 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0 (gdb) bt #0 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0 Cannot access memory at address 0x802627f08 (gdb) info thread Id Target Id Frame 2 process 172 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0 * 1 process 168 0x0000000800a84f1c in _umtx_wakeup_err () from /usr/lib/libpthread.so.0 (gdb) info reg rax 0x0 0 rbx 0x8006904e0 34366620896 rcx 0x802627f08 34399747848 rdx 0x80296fa00 34403187200 rsi 0x80296ff80 34403188608 rdi 0xb 11 rbp 0x802627f10 0x802627f10 rsp 0x802627f08 0x802627f08 r8 0x240 576 r9 0xffffffe098291380 -134886124672 r10 0x1 1 r11 0x20100017 537919511 r12 0x8006904e0 34366620896 r13 0x8006904f8 34366620920 r14 0x0 0 r15 0x8006900c0 34366619840 rip 0x800a84f1c 0x800a84f1c <_umtx_wakeup_err+12> eflags 0x10206 [ PF IF RF ] cs 0x2b 43 ss 0x23 35 ds *value not available* es *value not available* fs *value not available* gs *value not available* (gdb) x/1xb 0x800a84f1c 0x800a84f1c <_umtx_wakeup_err+12>: 0xc3 It means it cannot return (0xc3) from _umtx_wakeup_err (which is a system call). It happens all the time. I do not know why. Bug in OS, probably