A post on us...@httpd highlights inconsistent practice in apr.
On 17 Aug 2009, at 01:48, Peter Horn wrote:
Hi All,
I've been running Apache 2.2.9 / PHP 5.2.6 / Win XP SP3 with 3
named vhosts for about a year with no real problems. Recently I
added a fourth vhost to run a Drupal site. This involved adding
mySQL, and it all worked after the usual few setup iterations.
After the site was running happily for a couple of weeks, I
revisited the setup and removed 'DBDPersist Off' from the vhost.
After I did this, I get the following messages in the error log at
startup, even though the site subsequently appears to work
correctly and there are no 'runtime' errors:
[Sat Aug 15 12:25:22 2009] [error] (OS 126)The specified module
could not be found. : DBD: mod_dbd not compatible with APR in
get_driver
[Sat Aug 15 12:25:22 2009] [error] (OS 126)The specified module
could not be found. : DBD: failed to initialise
Problem: The user has got a confusing error message.
Diagnosis: apr_dso_load and apr_dso_sym on Windows platform
return an OS error instead of an APR error on failure.
As an APR user, mod_dbd handles the APR errors APR_EDSOOPEN
and APR_ESYMNOTFOUND and gives the user a tailored error
message. That was based on the behaviour of unix/apr_dso.
It's an inconsistency, and IMHO it's the Windows that should
be fixed. APR is supposed to shield applications from this
kind of platform-specific detail.
Quick survey of other APR platforms:
aix, beos, netware, os390 - conform to UNIX behaviour.
os2 - uses APR_FROM_OS_ERROR
So the safest/most consistent thing would seem to be to
fixup both Windows and OS2. Thoughts?
--
Nick Kew
