On Fri, 28 Mar 2003, Stas Bekman wrote: [ .. ]
Randy,
I've looked at this issue and I don't see this problem on linux. Admittedly there was a problem with using -apxs which was finding mod_perl.so when it wasn't supposed to, which I've fixed now in cvs.
Currently the logic goes like this (at this moment only relevant to mod_perl 2.0 built as DSO):
1. always ignore the whatever 'LoadModule perl_module path' was found in global httpd.conf (that's what pre_configure() does)
2. look at the build config options, if such exists (which is the case when mod_perl was installed on the system or we are inside the core build), use the information from there
3. otherwise die, saying oops, mod_perl is not installed
Currently I have two perl trees (I have many more but for the purpose of this explanation let's say I have just two): ~/perl/blead and ~/perl/blead-ithreads. I've installed mod_perl using ~/perl/blead-ithreads, but not ~/perl/blead.
Now if I build a 3rd party module with blead-ithreads, it automatically finds mod_perl.so, because it's in BuildOptions. No matter if I provide -httpd, -apxs or nothing at all.
If I build with blead (no mod_perl installed) it finds no mod_perl.so, no matter if I provide -httpd, -apxs or nothing at all.
Now, Randy, can you please tell whether this logic is flowed?
That sounds right, and looking at my (installed) Apache::BuildConfig, the basic info is there - MODPERL_LIB_DSO is
mod_perl.so, and MODPERL_AP_LIBEXEXDIR is set to the right
Apache2 modules/ directory. But for some reason it doesn't get
picked up on Win32 for 3rd party modules - in the generated
httpd.conf, a comment appears that mod_perl.so can't be located.
It may be that this has been fixed by some recent commits; unfortunately, something's broken on Win32 in the current cvs version (I get a "free to wrong pool" error and then an access violation in perl58.dll when the tests start up). I'll try to find some time later this week to look at this some more.
I haven't change the search logic, other than doing some preps for searching 1.0 and static build versions, so I suppose it hasn't been fixed. It should be very easy to trace why it doesn't find the shared library by adding some debug prints in Apache::TestConfigPerl::configure_libmodperl.
Thanks.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
