There’s a problem that’s being discussed on techie lists, but could probably use the marginal extra exposure of a blog entry here.

Symptom: An Apache+MySQL application works.  An Apache+PHP+MySQL application works.  But try to run them both on the same server, and it segfaults.

Diagnosis: PHP’s native MySQL support links the libmysqlclient.so client library, but Apache’s DBD (apr-dbd, part of the apr-util library that manages a dynamic connection pool) links the libmysqlclient_r.so client library.  Linking both libraries in the same executable creates a conflict, causing a crash.

The difference between the two libraries is that libmysqlclient_r.so is thread-safe and reentrant, whereas libmysqlclient.so only supports simple apps.  Since APR and Apache use threads, they must use the former version.  In PHP’s case, there is (AFAIK) no difference, so it could equally well use either version.  That leads us to

Solution 1: Rebuild PHP to use libmysqlclient_r.so.  Alternative (at your own risk) build apr-util with libmysqlclient.so.  The alternative will probably be fine with Apache if you use the prefork MPM (which you’re almost certainly already doing if you use PHP), but could screw up other APR applications that rely on thread-safety.

Could the same conflict reappear elsewhere?  I don’t know of any cases, but I wouldn’t rule it out.  So here’s a solution that’ll fix it once and all.  Globally!

Solution 2: Remove libmysqlclient.so and substitute a symlink to libmysqlclient_r.so.

I don’t know if there’s a downside to either of those solutions: don’t do anything irrevocable until you’ve tested! I guess libmysqlclient_r.so might have a bigger memory footprint than libmysqlclient.so in apps where either would work.  If any more serious issues come to my attention, I’ll document them here.