SQLite Threading FreeBSD CMUCL Oh My!

FreeBSD 4's "man pthread" says:

The current FreeBSD POSIX thread implementation is built in the library
libc_r which contains both thread-safe libc functions and the thread
functions.  This library replaces libc for threaded applications.
...
A FreeBSD specific option has been added to gcc to make linking threaded
processes simple.  gcc -pthread links a threaded process against libc_r
INSTEAD OF libc.

(Emphasis mine.)

SQLite uses pthreads on Unix. Its threadsafe operation requires each thread in a process to make a separate call to sqlite_open() and to use only the specific "sqlite" structure returned from the call.

Thus, on FreeBSD, a process that loads a multithreading SQLite shared library libsqlite.so also needs libc_r.so linked in. (The SQLite port builds a non-threading version.)

Here's where it gets fun:

$ ldd `which lisp`
/usr/local/bin/lisp:
        libm.so.2 => /usr/lib/libm.so.2 (0x28085000)
        libc.so.4 => /usr/lib/libc.so.4 (0x280a0000)

I use the following to load my multithreading libsqlite.so into lisp:

  (progn
    (system::load-object-file "/usr/lib/libc_r.so")
    (system::load-object-file *sqlite3-so-load-path*))

The problem is, lisp hits a weird looking error while exiting after using libsqlite.so. This is caused by linking both libc_r.so and libc.so into the same process.

When I build a non-threading libsqlite.so, the error doesn't occur, so I can use that, but it feels like an unreasonable constraint, because I don't yet know how my SQLite-using Lisp program will look like and it may be more natural to use a threading style.

So what to do? Say, I can build a lisp that links to libc_r.so directly. Yeah. That'll do it!

(To be continued.)