Spent quite a time to discover that pdo_sqlite PHP extension shipping with Slackware doesn't link against system sqlite3 but rather against bundled 3.3.7 version. This is hardly a big problem for PHP itself but it appears that Apache modules tend to use this bundled sqlite library instead of the system one which may lead to problems.

At my development server I use Trac issue tracker - a Python application "linked" to Apache via mod_wsgi. Trac uses Subversion bindings to access local repositories and while upgrading server to Subversion 1.6.4 from Slackware 13.0 I trapped an error in Trac: while trying to open the repository Subversion says it is linked against sqlite library 3.6.6.2 but working with 3.3.7 and stops processing. But when I used trac-admin command-line application there were no problems of this kind - Trac synchronized with the repositories just fine.

The most obvious solution was to fall back to "legacy" repository format not using sqlite features but it is not what we want so I tried to find this 3.3.7 sqlite everywhere on the server. The only place we still had 3.3.7 was in pdo_sqlite.so from PHP package - it seems that when Python interpreter linked to the Apache through mod_wsgi (and possibly through mod_python as well - don't see any dramatic difference) tries to load sqlite library it finds that sqlite library already loaded by pdo_sqlite extension and uses it instead of the system one. It's also possible that the Subversion modules may face the same problem if used in conjunction with mod_php. I didn't find any clues on this matter with Google I thought it might be useful for somebody out there.

The best solution will be to rebuild the php package with ... --with-pdo-sqlite=/usr,shared ... in SlackBuild but it will require some time and installation of many libraries which are not otherwise needed so it's faster to rebuild the pdo_sqlite extension only:

(note the LDFLAGS setting)

PS ... or maybe it's not worth to use mod_wsgi for Python applications in Slackware - just stick with CGI.