This post originated from an RSS feed registered with Python Buzz
by Ng Pheng Siong.
Original Post: SQLite Threading FreeBSD CMUCL Oh My!
Feed Title: (render-blog Ng Pheng Siong)
Feed URL: http://sandbox.rulemaker.net/ngps/rdf10_xml
Feed Description: Just another this here thing blog.
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.)
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!