Executive summary: Apache silently fails an SSI include, where the include'd HTML is generated by a C++ program which is linked with SQLite and/or pthreads. The SSI include works when the C++ doesn't use SQLite.
Longer version: I have two very similar C++ programs which produce the output required for an SSI virtual include. Both produce a list of about 100 options for an HTML select
. One of the includes works as expected, but the other one is doing nothing.
A
) is straightforward stand-alone C++ code, which uses the STL to produce a string, which is written to cout
; no problem.B
) is slightly more complicated. It's a mix of
C and C++, and includes an embedded SQLite
database, talking to it through the C API. SQLite also uses pthreads.B
fails both when it is linked to the static, and the dynamic, SQLite code. Both the static and dynamic versions depend on the pthreads shared library.B
, but it also substitutes nothing into the HTML select
. I can easily get Apache to produce
an error message (by specifying a wrong executable name in the HTML
#include
, for example) so I'm pretty sure that Apache does
actually at least attempt to execute the program.A
and B
are valgrind-clean.ScriptLog
, so I may have set it up incorrectly. I've set LogLevel
to debug
, but it still doesn't tell me anything about script execution.Any ideas? Thanks.
Well, that was irritating. The database was a symlink in the cgi-bin directory, which pointed somewhere else. The apache user didn't have search permission on the last directory in the pointed-to location. If I su
'ed to the Apache user, and then ran the CGI program manually, it returned a 400 error message. However, this didn't get to the Apache error.log
, even with LogLevel
set to debug
, and I can't get any ScriptLog
output, and firebug doesn't show anything in the net tab. Everything worked when I changed the directory permission.