apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: svn commit: r1211930 - /apr/apr-util/branches/1.4.x/crypto/apr_crypto.c
Date Thu, 08 Dec 2011 16:38:36 GMT
On 12/08/2011 05:15 PM, Graham Leggett wrote:
> On 08 Dec 2011, at 5:21 PM, mturk@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.


View raw message