On 12/08/2011 05:15 PM, Graham Leggett wrote:
On 08 Dec 2011, at 5:21 PM, mt...@apache.org wrote:
Author: mturk
Date: Thu Dec 8 15:21:21 2011
New Revision: 1211930
URL: http://svn.apache.org/viewvc?rev=1211930&view=rev
Log:
Fix broken macro. driver.init takes three params and we don't have second two
so pass NULL. We should consider dropping that entirely in favor of
apr_crypto_get_driver or make apr_crypto_get_driver statically aware. Something
for later versions to deal with
I have an alternative fix that moves DRIVER_LOAD from apr_crypto_init() to
apr_crypto_get_driver() so we don't lose the parameters, but I can't test it
because it seems the non-dso APR build currently doesn't work on unix at all
(not for crypto, nor for dbd). Most specifically, when building without dso
support, modules are neither built nor statically linked to APR, and so are
missing on startup leading to errors like this:
graham-leggetts-macbook-pro-3:test minfrin$ ./testall testdbd
dyld: Symbol not found: _apr_dbd_odbc_driver
Well in theory it could work by including the driver .c files
directly to apu if something like
--enable-static-foo is added to configure which would add foo.c to Makefile
instead compiling a separate lib/dso
Anyhow, too much effort for something we modularized just
because its optional (so I doubt any vendor will build it that way)
IMHO we should axe all static code and just rely on dynamic load.
If that means windows won't be able to have dbd, dbm, crypto modules
if compiled as static library, fine.
Regards
--
^TM
