Nils Breunese wrote: > Noah Kantrowitz wrote: >> It isn't PHP 4 vs 5, it is the fact that another Apache module is linked >> against a different version of sqlite than your pysqlite bindings. >> If/when it gets loaded first, that version takes priority and confuses >> pysqlite. This is contraint of the way Linux (and most other unixes) >> handle dynamic linking, and the fact that all Apache modules run within >> the same memory space. > > But I only have one version of sqlite as CentOS 4.4 comes with only one > version of sqlite (3.x) and I would think it would be very strange if > the PHP packages from the CentOSPlus repository (for CentOS 4.4) would > be linked against a version of sqlite that is not available on CentOS > 4.4. How can I check which versions of sqlite PHP and python are linked > against? Like I mentioned in my original post starting this thread I > already ran the following: > > >>> import trac.db.sqlite_backend > >>> trac.db.sqlite_backend._ver > (3, 3, 3) > >>> trac.db.sqlite_backend.have_pysqlite > 1 > >>> trac.db.sqlite_backend.sqlite.version > '1.1.7' > > sqlite 3.3.3 and python-sqlite 1.1.7 are the only sqlite-related > packages I have installed, but how can I check if PHP might be interfering?
Well, it seems it was indeed PHP interfering. I disabled the pdo_sqlite extension (commented it out in /etc/php.d/pdo_sqlite.ini), restarted apache and all the Trac projects were working! We're not using sqlite with PHP so it's not really a problem, but I wonder what the ultimate solution would be. Would the PHP package have to be altered to somehow use the same sqlite as Python? Nils Breunese.
signature.asc
Description: OpenPGP digital signature
