httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2 patch] getting APR to work w/o modperl
Date Wed, 19 May 2004 03:36:27 GMT
Randy Kobes wrote:
> On Mon, 17 May 2004, Stas Bekman wrote:
> [ ... ]
> 
>>Randy Kobes wrote:
>>
>>>I'll try it for Windows and see how much is involved; if
>>>this works as expected, it should just involve changing
>>>how things are compiled, as well as the order (APR.so coming
>>>first). But one of the joys of working with Windows is
>>>that things are never as expected ;)
> 
> 
> I've now tried it on Windows, and in particular the
> (patched) apr-ext tests pass. This though was manual;

Great!

> I'll next try to get things built automatically. But
> just for information, what was required was
> - adjust xs/APR/APR/APR.def to include
>     modperl_interp_unselect
>     modperl_hash_tie
>     modperl_hash_tied_object
>     modperl_perl_gensym
>     modperl_error_strerror
> in the list of exported symbols

We ought to automate that. I think you've missed symbols, like tracing 
functions, since you didn't build with tracing enabled or because the 
APR/Foo.o's that my patch tests don't use tracing. We should probably look at 
the the apache/apr DECLARE macros. Alternatively it can be a common group of 
files modperl_common_*.c but it'll be hard to extract those symbol names. 
Another approach is to split the tables/ModPerl/Functions.pm (which I think 
that's how .def is generated now). May be the function names should have a 
different prefix than /modperl_/. In which case it'll be clear that they are 
common ones.

> - build APR first, so APR::* can link against it (the
> default action is to build APR::* first);

Really? Is it specific to win32? On linux with the current cvs, I can run 
'make -j' which builds things in parallel and I was getting APR/*.so getting 
build while src/modules/perl/mod_perl.so was still not built. But I don't see 
problem with arranging what you did.

> - adjust the Makefiles in APR::* to link to
>      blib/arch/Apache2/auto/APR/APR.lib
> before linking to src/modules/perl/mod_perl.lib

Good.

> - add
>      blib/arch/Apache2/auto/APR/
> to the PATH, so APR.dll can be found (perhaps APR.dll
> [APR.so] should be installed to $APACHE2/lib or
> $APACHE2/bin, as appropriate?)

That's not good. The whole idea was not to create a library which will need to 
be searched by the loader. The ideas was to have a plain .so which will live 
under perl's lib, and loading any APR/Foo.pm will first load APR.so, and then 
APR/Foo.so. So yes, there is a need to change the autogenerated APR/*.pm 
files, but you shouldn't need to mess with PATH or anything that has to do 
with system-wide loader.

If we were to create a separate .so (read: win32/dll), that would be 
mod_perl_common.so since all these things in modperl_common.* have nothing to 
do with apr. But we want to avoid to impose that added enormous complexity on 
our users.

> In any case, no source code changes were needed - I think
> all the above can be done within the Makefile generation.

It's fine to change the source if it's needed :)

Good work, Randy!

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message