On Fri, 3 Oct 2003, Geoffrey Young wrote: > >> It may be that, at least for Win32, Apache/2.0.47 is needed; > >> http://marc.theaimsgroup.com/?l=apr-cvs&m=105631900723064&w=2 > >> indicates apr_table_compress() was added in apr 0.9.4, which > >> I think means Apache/2.0.47. > > > > > > Good catch, Randy. It indeed was added in 2.0.47 :( > > I don't understand what is happening here on win32. from > modperl_apache_compat.c: > > #if ! AP_MODULE_MAGIC_AT_LEAST(20020903,4) > > > /* added in APACHE_2_0_47/APR_0_9_4 */ > void apr_table_compress(apr_table_t *t, unsigned flags) > { > modperl_apr_func_not_implemented(apr_table_compress, 2.0.47, 0.9.4); > } > > > #endif /* pre-APR_0_9_5 (APACHE_2_0_47) */ > > so it should be defined for 2.0.46, just not available for > use. and 2.0.46 compiles just fine for me on linux. > > is win32 somehow not picking up the compat file, or is > there some additional logic that we need for this kind of > thing? I pretty much copied what was there before when we > had other APR back-compat issues.
I think it is a Win32 thing ... The missing apr_table_compress symbol comes when trying to build APR/Table.dll, and for pre Apache/2.0.47 this would be found in mod_perl.so (aka mod_perl.dll on Win32). When building APR/Table.dll the associated mod_perl.lib is included in the libraries to be linked against, but mod_perl.lib doesn't contain the full symbol definitions, which are in mod_perl.so. I've had similar problems before trying to build a dll which needs a symbol that's found in another dll; I think some fiddling with the definition of the symbol in the 2nd dll may be needed. I could try doing that, which might be also useful later on down the road ... -- best regards, randy