| Subject: | mod_perl and DBD::SQLite::db prepare failed: not an error |
For the impatient: I will post a possible workaround in my next comment.
The problem occurs on current Redhat systems, for example RHEL 5 or the
CentOS equivalent but is probably not specific to Redhat.
In brief, the reason for the behavior is that under mod_perl DBD::SQLite
executes the sqlite3 functions mostly from /usr/lib64/libsqlite3.so.0
and not the built-in one. The symbol "sqlite_prepare_v2" however is not
defined in the system-wide sqlite3.so.0 and therefore the built-in code
is executed for that particular function. That mixtures wrecks havoc.
In detail: These are the versions of the packages that take part in the
problem:
# rpm -q mod_perl httpd php php-mysql sqlite
mod_perl-2.0.4-6.el5
httpd-2.2.3-43.el5
php-5.1.6-27.el5
php-mysql-5.1.6-27.el5
sqlite-3.3.6-5
When you start apache, it loads both mod_perl and mod_php5, and the
latter is linked against libsqlite3.so.0:
# lsof /usr/lib64/libsqlite3.so.0
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd 11665 root mem REG 8,2 373352 74214
/usr/lib64/libsqlite3.so.0.8.6
httpd 11667 apache mem REG 8,2 373352 74214
/usr/lib64/libsqlite3.so.0.8.6
etc. for the other preforked children.
Now, when the symbols from DBD/SQLite.so are resolved by the dynamic
linker, most of the code is already loaded via the system-wide sqlite3
(thanks to mod_php5). But "sqlite3_prepare_v2" was introduced after
sqlite version 3.3.6, and therefore this particular symbol (and most
probably others) are resolved from the built-in sqlite3.o (the one that
ships with DBD-SQLite).
I guess that this is not a Redhat problem but always occurs, when
another apache module is linked against libsqlite3.so. The problem is
visible only here because the installed sqlite shared library is so old.
I tried to define SQLITE_API to "static" and SQLITE_EXTERN to the empty
string in sqlite3.h. But that is not enough. You run into relocation
problems, even if you compile everything with -fPIC. But if you want to
address the problem in DBD-SQLite, that is probably the way to go.
BTW, many thanks to Viktor Kojouharov and Slavi Agafonkin for analyzing
the problem.
I think that this ticket is in fact a duplicate or earlier ones. I
still wanted to open a new one because it will help people find a
solution. Sorry for that egoism. ;-)