Hi, On Wednesday 11 April 2012, Jan Kaluža wrote: > I've talked with Torsten about the mod_perl and httpd-2.4 > compatibility and he advised me to start discussion about this > problem. > > Attached patch against httpd24 branch fixes the compilation with > httpd-2.4. I was not able to generate xs using "make source_scan", > so I've changed them manually. Should source_scan.pl work...? > > Except the source_scan.pl issue, there is one issue which has to be > addressed too.
If have hacked a bit on it and I succeeded to make source_scan work, but for some reason it doesn't generate code for mpxs_APR__Table_FETCH, i.e. it is removed from xs/tables/current/ModPerl/FunctionTable.pm. This makes "make test" fail on startup with: [Tue Apr 24 23:34:20.469091 2012] [perl:error] [pid 25417:tid 1434549712] $s->add_config() has failed: Can't locate object method "FETCH" via package "APR::Table" at .../mod_perl/blib/lib/Apache2/PerlSections.pm line 40.\nCompilation failed in require at .../mod_perl/t/conf/modperl_startup.pl line 18. \n\t...propagated at .../mod_perl/t/conf/modperl_startup.pl line 19. \nBEGIN failed--compilation aborted at .../mod_perl/t/conf/modperl_startup.pl line 36.\nCompilation failed in require at (eval 2) line 1.\n [Tue Apr 24 23:34:20.469205 2012] [perl:error] [pid 25417:tid 1434549712] Can't load Perl file: .../mod_perl/t/conf/modperl_startup.pl for server localhost:8529, exiting... [ error] Any idea what goes wrong here? I have started from a merge of branch httpd24 into trunk (because I have perl 5.14 and it seemed to me that the httpd24 branch does not support that yet). I also had to add a LFS related patch from the Debian package (http://patch- tracker.debian.org/patch/series/dl/libapache2-mod-perl2/2.0.5-5/250- lfs-perl-5.14.patch). A bunch of patches that may be committable are at http://people.apache.org/~sf/mod_perl/ > conn_rec->remote_ip and conn_rec->remote_addr have been removed and > replaced by request_rec->useragent_ip, request_rec->useragent_addr > and conn_rec->client_ip, conn_rec->client_addr. See [1] to read > about the differences between them. > > There are two ways how to address this issue: > > 1. Break the compatibility with older mod_perl versions. The > advantage is that mod_perl will stay consistent with httpd and > mod_perl developers would not have to maintain the compatibility > layer. > > The disadvantage is that if there are projects using mod_perl and > remote_ip/remote_addr, they would have to be fixed too. However, > it's the very same situation like with httpd-2.4, where all the > modules using remote_ip/remote_addr have to be fixed too. > > 2. Introduce the compatibility layer. I'm not Perl expert, but I > think with the way how mod_perl is built currently it's not doable > out-of-box (I can be wrong of course). > > Interesting thing is also that most modules I've ported to > httpd-2.4 use remote_ip/remote_addr in the meaning of > useragent_ip/useragent_addr. In http-2.4 these two pairs are > members of different structs (conn_rec and request_rec). I think I > can't imagine how would we map > conn_rec->remote_ip to request_rec->useragent_ip... > > > Personally I would vote for the number 1 and bumping mod_perl > version. There are more compatibility issues. For example, ap_requires() is gone in 2.4. This may make some auth-related modules fail. > > I'm not Perl developer, I just co-maintain mod_perl in Fedora and > in the development version httpd has been updated to 2.4, so > mod_perl is not building there anymore. Unfortunately, I have no experience with mod_perl either. I am Debian httpd maintainer and we would like to ship the next Debian release (wheezy) with httpd 2.4, so we are interested in having a usable mod_perl soonish. Do you have any suggestions on how we could reach that goal? Cheers, Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
