Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: Dev

mod_perl and httpd-2.4

 

 

ModPerl dev RSS feed   Index | Next | Previous | View Threaded


jkaluza at redhat

Apr 10, 2012, 11:44 PM

Post #1 of 16 (4536 views)
Permalink
mod_perl and httpd-2.4

Hi,

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.

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.

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.

Regards,
Jan Kaluza
Attachments: modperl-httpd24.patch (2.56 KB)


sf at sfritsch

Apr 24, 2012, 3:10 PM

Post #2 of 16 (4471 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


sf at sfritsch

May 5, 2012, 2:51 PM

Post #3 of 16 (4437 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

Hi,

On Wednesday 25 April 2012, Stefan Fritsch wrote:
> 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?

Is there any mod_perl developer who is expecting to have time for the
2.4 upgrade in the near future? We are currently trying to figure out
if we should go ahead with the upgrade to 2.4. If that would mean not
having mod_perl, we would stay with 2.2 instead.

Cheers,
Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

May 7, 2012, 9:26 PM

Post #4 of 16 (4434 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On Tue, Apr 10, 2012 at 11:44 PM, Jan KaluĹľa <jkaluza [at] redhat> 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...?

What changes to source_scan.pl did you have to make?

I've gotten httpd 2.4 to compile successfully, and I think this patch
will work in terms of the api changes, but it needs to provide the
appropriate method depending on the httpd minor version, remote_ip for
2.0, 2.2 and client_ip for 2.4. I'm not sure where that happens yet in
the codebase - maybe FunctionTable.pm?

I would favor the compatibility layer approach personally. I have some
code on CPAN that uses remote_ip, so I don't really want to go change
that to support 2.4 just yet.


>
> Except the source_scan.pl issue, there is one issue which has to be
> addressed too.
>
> 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.
>
> 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.
>
> Regards,
> Jan Kaluza
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe [at] perl
> For additional commands, e-mail: dev-help [at] perl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


jkaluza at redhat

May 9, 2012, 12:40 AM

Post #5 of 16 (4431 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 05/08/2012 06:26 AM, Fred Moyer wrote:
> On Tue, Apr 10, 2012 at 11:44 PM, Jan KaluĹľa<jkaluza [at] redhat> 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...?
>
> What changes to source_scan.pl did you have to make?

So far I've the attached patch to compile mod_perl-2.0.6 against
httpd-2.4. It's based on Stefan's patches. The only problem I have now
is that after running source_scan and building mod_perl, ModPerl::Global
is not included which causes later runtime failure. I'm not sure why it
behaves like that and I'm in state of debugging this problem, but help
is welcome.

>
> I've gotten httpd 2.4 to compile successfully, and I think this patch
> will work in terms of the api changes, but it needs to provide the
> appropriate method depending on the httpd minor version, remote_ip for
> 2.0, 2.2 and client_ip for 2.4. I'm not sure where that happens yet in
> the codebase - maybe FunctionTable.pm?

Right, those patches only hardcodes it for httpd-2.4. The next step
should be to probably put #ifdefs around remote_ip. Other things should
be done by source_scan script I believe.

> I would favor the compatibility layer approach personally. I have some
> code on CPAN that uses remote_ip, so I don't really want to go change
> that to support 2.4 just yet.

If you find a way how to do it, tell me :). As I said, I think 90% of
httpd modules uses remote_ip/remote_addr in the meaning of
useragent_ip/useragent_addr.

So, there's currently used conn_rec->remote_ip and new
request_rec->useragent_ip. I can't imagine how would you write some
layer to map current conn_rec->remote_ip to request_rec->remote_ip,
since there's no way how to get particular request_rec from conn_rec. I
just think it can't be done transparently and there will be need to
change the modules anyway...

Regards,
Jan Kaluza
Attachments: mod_perl-httpd24.patch (15.3 KB)


jkaluza at redhat

May 10, 2012, 1:13 AM

Post #6 of 16 (4437 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 05/09/2012 09:40 AM, Jan Kaluža wrote:
> On 05/08/2012 06:26 AM, Fred Moyer wrote:
>> On Tue, Apr 10, 2012 at 11:44 PM, Jan Kaluža<jkaluza [at] redhat> 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...?
>>
>> What changes to source_scan.pl did you have to make?
>
> So far I've the attached patch to compile mod_perl-2.0.6 against
> httpd-2.4. It's based on Stefan's patches. The only problem I have now
> is that after running source_scan and building mod_perl, ModPerl::Global
> is not included which causes later runtime failure. I'm not sure why it
> behaves like that and I'm in state of debugging this problem, but help
> is welcome.

Finally found out that CScan doesn't parse inline methods and this is
why ModPerl::Global is omitted. I've "fixed" this by adding defitions
for ModPerl::Global methods, so CScan parses them correctly now. The
proper fix would be probably to fix CScan, but I think my Perl knowledge
is not so good...

So, attached patch is everything I needed to compile modperl-2.0.6
against httpd-2.4.

Note that you have to run "make source_scan" and "make xs_generate" and
rerun MakeFile.pl before executing "make".

Regards,
Jan Kaluza
Attachments: mod_perl-httpd24.patch (14.2 KB)


sf at sfritsch

May 13, 2012, 7:45 AM

Post #7 of 16 (4396 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On Wednesday 09 May 2012, Jan Kalu¸a wrote:
> > I would favor the compatibility layer approach personally. I have
> > some code on CPAN that uses remote_ip, so I don't really want to
> > go change that to support 2.4 just yet.
>
> If you find a way how to do it, tell me :). As I said, I think 90%
> of httpd modules uses remote_ip/remote_addr in the meaning of
> useragent_ip/useragent_addr.
>
> So, there's currently used conn_rec->remote_ip and new
> request_rec->useragent_ip. I can't imagine how would you write
> some layer to map current conn_rec->remote_ip to
> request_rec->remote_ip, since there's no way how to get particular
> request_rec from conn_rec. I just think it can't be done
> transparently and there will be need to change the modules
> anyway...

Also, conn_rec->remote_ip is probably the smaller issue compared to
ap_requires() being gone. IMHO, there is no way to implement $r-
>requires() in a compatible way. So at least all modules doing
authorization need be changed to use the new APIs.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


jkaluza at redhat

Jun 4, 2012, 4:46 AM

Post #8 of 16 (4349 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 05/09/2012 09:40 AM, Jan Kaluža wrote:
> Right, those patches only hardcodes it for httpd-2.4. The next step
> should be to probably put #ifdefs around remote_ip. Other things should
> be done by source_scan script I believe.
>

I've splitted the patch into separate patches. This is against
mod_perl-2.0.6. With those patches, mod_perl compiles against httpd-2.2
and also against httpd-2.4. It's based on the Stefan's work.

http://jkaluza.fedorapeople.org/mod_perl/

>> I would favor the compatibility layer approach personally. I have some
>> code on CPAN that uses remote_ip, so I don't really want to go change
>> that to support 2.4 just yet.
>
> If you find a way how to do it, tell me :). As I said, I think 90% of
> httpd modules uses remote_ip/remote_addr in the meaning of
> useragent_ip/useragent_addr.
>
> So, there's currently used conn_rec->remote_ip and new
> request_rec->useragent_ip. I can't imagine how would you write some
> layer to map current conn_rec->remote_ip to request_rec->remote_ip,
> since there's no way how to get particular request_rec from conn_rec. I
> just think it can't be done transparently and there will be need to
> change the modules anyway...
>
> Regards,
> Jan Kaluza
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe [at] perl
> For additional commands, e-mail: dev-help [at] perl

Regards,
Jan Kaluza

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


KMcGrail at PCCC

Jun 4, 2012, 5:21 PM

Post #9 of 16 (4358 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 6/4/2012 7:46 AM, Jan Kaluža wrote:
> On 05/09/2012 09:40 AM, Jan Kaluža wrote:
>> Right, those patches only hardcodes it for httpd-2.4. The next step
>> should be to probably put #ifdefs around remote_ip. Other things should
>> be done by source_scan script I believe.
>>
>
> I've splitted the patch into separate patches. This is against
> mod_perl-2.0.6. With those patches, mod_perl compiles against
> httpd-2.2 and also against httpd-2.4. It's based on the Stefan's work.
>
> http://jkaluza.fedorapeople.org/mod_perl/
I can't repeat your success because I can't compile against 2.4.

Specifically, Compiling against Apache 2.4.1 from source, I've tried the
mod_perl 2.0.6 release with these patches on a CentOS 6.2 x64 system
with a little bit of trouble.

Your patches apply cleanly but I throw this error trying to make based
on the following config command: perl Makefile.PL
MP_APXS=/usr/local/apache2/bin/apxs
MP_APR_CONFIG=/usr/local/apache2/bin/apr-1-config

modperl_constants.c: In function 'modperl_constants_lookup_apache2_const':
modperl_constants.c:809: error: 'OPT_INCNOEXEC' undeclared (first use in
this function)
modperl_constants.c:809: error: (Each undeclared identifier is reported
only once
modperl_constants.c:809: error: for each function it appears in.)
make[1]: *** [modperl_constants.lo] Error 1
make[1]: Leaving directory `/usr/src/mod_perl-2.0.6/src/modules/perl'
make: *** [modperl_lib] Error 2

Looking at ./src/modules/perl/modperl_constants.c has two references to
OPT_INCNOEXEC.

This comes from ./xs/tables/current/Apache2/ConstantsTable.pm referring
to OPT_INCNOEXEC. If I remove that entry I get a lot further until I
get to this error:

Connection.xs: In function 'XS_Apache2__Connection_remote_addr':
Connection.xs:117: error: 'conn_rec' has no member named 'remote_addr'
Connection.xs: In function 'XS_Apache2__Connection_remote_ip':
Connection.xs:134: error: 'conn_rec' has no member named 'remote_ip'
Connection.xs:138: error: 'conn_rec' has no member named 'remote_ip'
make[3]: *** [Connection.o] Error 1
make[3]: Leaving directory
`/usr/src/mod_perl-2.0.6/WrapXS/Apache2/Connection'
make[2]: *** [subdirs] Error 2
make[2]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS/Apache2'
make[1]: *** [subdirs] Error 2
make[1]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS'
make: *** [subdirs] Error 2

To fix those, I edited apache2_structures.map & StructureTable.pm to
change remote_addr and remote_ip to client_addr and client_ip

That got me to:

ServerRec.xs: In function 'XS_Apache2__ServerRec_loglevel':
ServerRec.xs:160: error: 'server_rec' has no member named 'loglevel'
ServerRec.xs:164: error: 'server_rec' has no member named 'loglevel'
make[3]: *** [ServerRec.o] Error 1
make[3]: Leaving directory
`/usr/src/mod_perl-2.0.6/WrapXS/Apache2/ServerRec'
make[2]: *** [subdirs] Error 2
make[2]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS/Apache2'
make[1]: *** [subdirs] Error 2
make[1]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS'
make: *** [subdirs] Error 2

To fix that, I changed the /xs/tables/current/Apache2/StructureTable.pm
to point to log.level instead of loglevel.

That got me compiled. A make test fails pretty badly though so not sure
what state tests are in.

[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /usr/src/mod_perl-2.0.6/t/TEST
-bugreport -verbose=0
/usr/local/apache2/bin/httpd -d /usr/src/mod_perl-2.0.6/t -f
/usr/src/mod_perl-2.0.6/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.4.1 (event MPM)

waiting 300 seconds for server to start: .[Mon Jun 04 20:00:02.886169
2012] [env:warn] [pid 2704:tid 139952181413632] AH01506: PassEnv
variable LD_LIBRARY_PATH was undefined
[ error] oh crap, server dumped core
[ error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core
/usr/src/mod_perl-2.0.6/core.2704
[ error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
[ error] oh jeez, server dumped core
[ error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core
/usr/src/mod_perl-2.0.6/core.2704
sh: line 1: 2599 Terminated /usr/bin/perl
/usr/src/mod_perl-2.0.6/t/TEST -bugreport -verbose=0
make: *** [run_tests] Error 143

Patch with the extra changes I needed are attached. Perhaps it can
help. If someone can give me direction I can perform more testing, etc.

regards,
KAM
Attachments: more_KAM_2.4-mp2.patch (1.73 KB)


jkaluza at redhat

Jun 4, 2012, 11:41 PM

Post #10 of 16 (4351 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 06/05/2012 02:21 AM, Kevin A. McGrail wrote:
> On 6/4/2012 7:46 AM, Jan Kaluža wrote:
>> On 05/09/2012 09:40 AM, Jan Kaluža wrote:
>>> Right, those patches only hardcodes it for httpd-2.4. The next step
>>> should be to probably put #ifdefs around remote_ip. Other things should
>>> be done by source_scan script I believe.
>>>
>>
>> I've splitted the patch into separate patches. This is against
>> mod_perl-2.0.6. With those patches, mod_perl compiles against
>> httpd-2.2 and also against httpd-2.4. It's based on the Stefan's work.
>>
>> http://jkaluza.fedorapeople.org/mod_perl/
> I can't repeat your success because I can't compile against 2.4.

The files you are editing below are generated automatically using
following commands:

make source_scan
make xs_generate

If you run those before compilation, it will regenerate the files you've
edited manually according to current httpd-2.4 headers.

This is part of spec file (file used to prepare .rpm packages)
describing how I build mod_perl against httpd-2.4:

CFLAGS="$RPM_OPT_FLAGS -fpic" %{__perl} Makefile.PL </dev/null \
PREFIX=$RPM_BUILD_ROOT/%{_prefix} \
INSTALLDIRS=vendor \
MP_APXS=%{_httpd_apxs} \
MP_APR_CONFIG=%{_bindir}/apr-1-config

make source_scan
make xs_generate

CFLAGS="$RPM_OPT_FLAGS -fpic" %{__perl} Makefile.PL </dev/null \
PREFIX=$RPM_BUILD_ROOT/%{_prefix} \
INSTALLDIRS=vendor \
MP_APXS=%{_httpd_apxs} \
MP_APR_CONFIG=%{_bindir}/apr-1-config


make -C src/modules/perl %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS -fpic"
make

Those configuration variables I pass to Makefile.PL can be skipped
probably. They are there just to find everything properly during the
building and install everything into proper directories to be used later
during packaging.

> Specifically, Compiling against Apache 2.4.1 from source, I've tried the
> mod_perl 2.0.6 release with these patches on a CentOS 6.2 x64 system
> with a little bit of trouble.
>
> Your patches apply cleanly but I throw this error trying to make based
> on the following config command: perl Makefile.PL
> MP_APXS=/usr/local/apache2/bin/apxs
> MP_APR_CONFIG=/usr/local/apache2/bin/apr-1-config
>
> modperl_constants.c: In function 'modperl_constants_lookup_apache2_const':
> modperl_constants.c:809: error: 'OPT_INCNOEXEC' undeclared (first use in
> this function)
> modperl_constants.c:809: error: (Each undeclared identifier is reported
> only once
> modperl_constants.c:809: error: for each function it appears in.)
> make[1]: *** [modperl_constants.lo] Error 1
> make[1]: Leaving directory `/usr/src/mod_perl-2.0.6/src/modules/perl'
> make: *** [modperl_lib] Error 2
>
> Looking at ./src/modules/perl/modperl_constants.c has two references to
> OPT_INCNOEXEC.
>
> This comes from ./xs/tables/current/Apache2/ConstantsTable.pm referring
> to OPT_INCNOEXEC. If I remove that entry I get a lot further until I get
> to this error:
>
> Connection.xs: In function 'XS_Apache2__Connection_remote_addr':
> Connection.xs:117: error: 'conn_rec' has no member named 'remote_addr'
> Connection.xs: In function 'XS_Apache2__Connection_remote_ip':
> Connection.xs:134: error: 'conn_rec' has no member named 'remote_ip'
> Connection.xs:138: error: 'conn_rec' has no member named 'remote_ip'
> make[3]: *** [Connection.o] Error 1
> make[3]: Leaving directory
> `/usr/src/mod_perl-2.0.6/WrapXS/Apache2/Connection'
> make[2]: *** [subdirs] Error 2
> make[2]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS/Apache2'
> make[1]: *** [subdirs] Error 2
> make[1]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS'
> make: *** [subdirs] Error 2
>
> To fix those, I edited apache2_structures.map & StructureTable.pm to
> change remote_addr and remote_ip to client_addr and client_ip
>
> That got me to:
>
> ServerRec.xs: In function 'XS_Apache2__ServerRec_loglevel':
> ServerRec.xs:160: error: 'server_rec' has no member named 'loglevel'
> ServerRec.xs:164: error: 'server_rec' has no member named 'loglevel'
> make[3]: *** [ServerRec.o] Error 1
> make[3]: Leaving directory
> `/usr/src/mod_perl-2.0.6/WrapXS/Apache2/ServerRec'
> make[2]: *** [subdirs] Error 2
> make[2]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS/Apache2'
> make[1]: *** [subdirs] Error 2
> make[1]: Leaving directory `/usr/src/mod_perl-2.0.6/WrapXS'
> make: *** [subdirs] Error 2
>
> To fix that, I changed the /xs/tables/current/Apache2/StructureTable.pm
> to point to log.level instead of loglevel.
>
> That got me compiled. A make test fails pretty badly though so not sure
> what state tests are in.
>
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/bin/perl /usr/src/mod_perl-2.0.6/t/TEST
> -bugreport -verbose=0
> /usr/local/apache2/bin/httpd -d /usr/src/mod_perl-2.0.6/t -f
> /usr/src/mod_perl-2.0.6/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
> using Apache/2.4.1 (event MPM)
>
> waiting 300 seconds for server to start: .[Mon Jun 04 20:00:02.886169
> 2012] [env:warn] [pid 2704:tid 139952181413632] AH01506: PassEnv
> variable LD_LIBRARY_PATH was undefined
> [ error] oh crap, server dumped core
> [ error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core
> /usr/src/mod_perl-2.0.6/core.2704
> [ error]
> server has died with status 255 (t/logs/error_log wasn't created, start
> the server in the debug mode)
> [ error] oh jeez, server dumped core
> [ error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core
> /usr/src/mod_perl-2.0.6/core.2704
> sh: line 1: 2599 Terminated /usr/bin/perl /usr/src/mod_perl-2.0.6/t/TEST
> -bugreport -verbose=0
> make: *** [run_tests] Error 143
>
> Patch with the extra changes I needed are attached. Perhaps it can help.
> If someone can give me direction I can perform more testing, etc.
>
> regards,
> KAM

Regards,
Jan Kaluza

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


KMcGrail at PCCC

Jun 5, 2012, 6:19 AM

Post #11 of 16 (4351 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 6/5/2012 2:41 AM, Jan Kaluža wrote:
> The files you are editing below are generated automatically using
> following commands:
>
> make source_scan
> make xs_generate
>
> If you run those before compilation, it will regenerate the files
> you've edited manually according to current httpd-2.4 headers.
Thanks. I've never run those commands before but had a feeling something
like them existed when I was ready the auto-generated warnings.

At the moment, make source_scan doesn't work for me though. Errors below.

Are you able to run a make test with your build?

make source_scan
/usr/bin/perl build/source_scan.pl
In file included from .apache_includes:91,
from <stdin>:1:
/usr/local/apache2/include/mod_cache.h:34:26: error: cache_common.h: No
such file or directory
In file included from .apache_includes:91,
from <stdin>:1:
/usr/local/apache2/include/mod_cache.h:34:26: error: cache_common.h: No
such file or directory
panic: multiple types without intervening comma in
' int(*ap_vhost_iterate_conn_cb)(void* baton, conn_rec* conn,
server_rec* s)'
whited-out as
'
int(*ap_vhost_iterate_conn_cb)( )'
panic: multiple types without intervening comma in
' const char PL_GYes_t[sizeof(" ")]'
whited-out as
' PL_GYes_t[sizeof(" ")]'
panic: multiple types without intervening comma in
' const char PL_GNo_t[sizeof("")]'
whited-out as
' PL_GNo_t[sizeof("")]'
panic: multiple types without intervening comma in
' const char
PL_Ghexdigit_t[sizeof(" ")]'
whited-out as
'
PL_Ghexdigit_t[sizeof(" ")]'
panic: multiple types without intervening comma in
' const char
PL_Gpatleave_t[sizeof(" ")]'
whited-out as
'
PL_Gpatleave_t[sizeof(" ")]'
Expecting parenth after identifier in `const XML_Memory_Handling_Suite
*memsuite'
after `const XML_Memory_Handling_Suite ' at lib/ModPerl/CScan.pm line 893.
at lib/ModPerl/CScan.pm line 893
ModPerl::CScan::do_declaration1('const
XML_Memory_Handling_Suite *memsuite', 'HASH(0x1d587c8)',
'HASH(0x1d67008)', 1) called at lib/ModPerl/CScan.pm line 844

ModPerl::CScan::do_declaration('XML_Parser\x{a}XML_ParserCreate_MM(const
XML_Char *encoding,\x{a} ...', 'HASH(0x1d587c8)', 'HASH(0x1d67008)')
called at lib/ModPerl/CScan.pm line 762
ModPerl::CScan::do_declarations('ARRAY(0x1db0090)',
'HASH(0x1d587c8)', 'HASH(0x1d67008)') called at
/usr/local/share/perl5/Data/Flow.pm line 93

Data::Flow::request('Apache2::ParseSource::Scan=ARRAY(0x1d9c908)',
'parsed_fdecls') called at /usr/local/share/perl5/Data/Flow.pm line 46
Data::Flow::get('Apache2::ParseSource::Scan=ARRAY(0x1d9c908)',
'parsed_fdecls') called at lib/Apache2/ParseSource.pm line 68

Apache2::ParseSource::Scan::get('Apache2::ParseSource::Scan=ARRAY(0x1d9c908)',
'parsed_fdecls') called at lib/Apache2/ParseSource.pm line 400

Apache2::ParseSource::get_functions('Apache2::ParseSource=HASH(0x1db6da8)')
called at lib/Apache2/ParseSource.pm line 496

Apache2::ParseSource::write_functions_pm('Apache2::ParseSource=HASH(0x1db6da8)')
called at build/source_scan.pl line 18
make: *** [source_scan] Error 1

Regards,
KAM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


jkaluza at redhat

Jul 25, 2012, 2:03 AM

Post #12 of 16 (4213 views)
Permalink
Re: mod_perl and httpd-2.4 - update [In reply to]

Hi,

I've been working on mod_perl and httpd-2.4 compatibility again. Current
status is that I'm able to compile mod_perl with httpd-2.4 on Fedora 17
(I haven't tested it on different systems) and "make test" more or less
works.

Since the last update it's huge step forward, because "make test" failed
just in the beginning previously and mod_perl with httpd-2.4 was quite
useless (just hello world examples worked).

With my latest patches [1] mod_perl looks usable to me and there are
only few tests which fails. Many of those tests have to be rewritten,
because the features they are testing have changed in httpd-2.4.

"Failed 19/242 test programs. 16/2701 subtests failed."

There are some controversial patches with hardcoded things which should
be fixed too, but I'm not the right person to come with right solution
so far.

1. 0020-Link-APR.so-against-libaprutil-1.patch
APR.so needs apr_bucket* functions which comes from aprutil, but it is
not linked against aprutil for me. I've hardcoded -laprutil-1 in the
Makefile.pl because I'm not sure how Build.pm is supposed to work.

2. 0023-Define-perl_module-in-Const.xs.patch
Thanks to modperl header files Const.so needs extern perl_module symbol
but this symbol is not defined in Const.xs. I've defined it there, but
this definitely need some clean solution.

[1] http://jkaluza.fedorapeople.org/mod_perl/

Regards,
Jan Kaluza

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


jkaluza at redhat

Jul 25, 2012, 3:52 AM

Post #13 of 16 (4218 views)
Permalink
Re: mod_perl and httpd-2.4 [In reply to]

On 06/05/2012 03:19 PM, Kevin A. McGrail wrote:> On 6/5/2012 2:41 AM,
Jan Kaluža wrote:
>> The files you are editing below are generated automatically using
>> following commands:
>>
>> make source_scan
>> make xs_generate
>>
>> If you run those before compilation, it will regenerate the files
>> you've edited manually according to current httpd-2.4 headers.
> Thanks. I've never run those commands before but had a feeling something
> like them existed when I was ready the auto-generated warnings.
>
> At the moment, make source_scan doesn't work for me though. Errors
below.

This should be fixed by patch 0027 at
http://jkaluza.fedorapeople.org/mod_perl/ . If it chokes on another
method from some file in /usr/include, you will have to do the same as I
do in patch 0027 for expat and byteswap.

> Are you able to run a make test with your build?
>
> make source_scan
> /usr/bin/perl build/source_scan.pl
> In file included from .apache_includes:91,
> from <stdin>:1:
> /usr/local/apache2/include/mod_cache.h:34:26: error: cache_common.h: No
> such file or directory
> In file included from .apache_includes:91,
> from <stdin>:1:
> /usr/local/apache2/include/mod_cache.h:34:26: error: cache_common.h: No
> such file or directory
> panic: multiple types without intervening comma in
> ' int(*ap_vhost_iterate_conn_cb)(void* baton, conn_rec* conn,
> server_rec* s)'
> whited-out as
> '
> int(*ap_vhost_iterate_conn_cb)(
)'
> panic: multiple types without intervening comma in
> ' const char PL_GYes_t[sizeof(" ")]'
> whited-out as
> ' PL_GYes_t[sizeof(" ")]'
> panic: multiple types without intervening comma in
> ' const char PL_GNo_t[sizeof("")]'
> whited-out as
> ' PL_GNo_t[sizeof("")]'
> panic: multiple types without intervening comma in
> ' const char
> PL_Ghexdigit_t[sizeof(" ")]'
> whited-out as
> ' PL_Ghexdigit_t[sizeof(" ")]'
> panic: multiple types without intervening comma in
> ' const char
> PL_Gpatleave_t[sizeof(" ")]'
> whited-out as
> '
> PL_Gpatleave_t[sizeof(" ")]'
> Expecting parenth after identifier in `const XML_Memory_Handling_Suite
> *memsuite'
> after `const XML_Memory_Handling_Suite ' at lib/ModPerl/CScan.pm line
893.
> at lib/ModPerl/CScan.pm line 893
> ModPerl::CScan::do_declaration1('const
> XML_Memory_Handling_Suite *memsuite', 'HASH(0x1d587c8)',
> 'HASH(0x1d67008)', 1) called at lib/ModPerl/CScan.pm line 844
> ModPerl::CScan::do_declaration('XML_Parser\x{a}XML_ParserCreate_MM(const
> XML_Char *encoding,\x{a} ...', 'HASH(0x1d587c8)', 'HASH(0x1d67008)')
> called at lib/ModPerl/CScan.pm line 762
> ModPerl::CScan::do_declarations('ARRAY(0x1db0090)',
> 'HASH(0x1d587c8)', 'HASH(0x1d67008)') called at
> /usr/local/share/perl5/Data/Flow.pm line 93
> Data::Flow::request('Apache2::ParseSource::Scan=ARRAY(0x1d9c908)',
> 'parsed_fdecls') called at /usr/local/share/perl5/Data/Flow.pm line 46
> Data::Flow::get('Apache2::ParseSource::Scan=ARRAY(0x1d9c908)',
> 'parsed_fdecls') called at lib/Apache2/ParseSource.pm line 68
>
Apache2::ParseSource::Scan::get('Apache2::ParseSource::Scan=ARRAY(0x1d9c908)',

> 'parsed_fdecls') called at lib/Apache2/ParseSource.pm line 400
>
Apache2::ParseSource::get_functions('Apache2::ParseSource=HASH(0x1db6da8)')
> called at lib/Apache2/ParseSource.pm line 496
>
Apache2::ParseSource::write_functions_pm('Apache2::ParseSource=HASH(0x1db6da8)')

> called at build/source_scan.pl line 18
> make: *** [source_scan] Error 1
>
> Regards,
> KAM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe [at] perl
> For additional commands, e-mail: dev-help [at] perl
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


KMcGrail at PCCC

Aug 20, 2012, 2:03 PM

Post #14 of 16 (4105 views)
Permalink
Re: mod_perl and httpd-2.4 - update [In reply to]

On 7/25/2012 5:03 AM, Jan Kaluža wrote:
> With my latest patches [1] mod_perl looks usable to me and there are
> only few tests which fails. Many of those tests have to be rewritten,
> because the features they are testing have changed in httpd-2.4.

Jan,

I'm trying to work on testing the patches and extrapolate on your work.
However, I'm having problems cleanly patching.

If I use http://jkaluza.fedorapeople.org/mod_perl/all.tgz, what version
of mod_perl should I be patching against?

Regards,
KAM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


KMcGrail at PCCC

Aug 20, 2012, 2:26 PM

Post #15 of 16 (4093 views)
Permalink
Re: mod_perl and httpd-2.4 - update [In reply to]

On 8/20/2012 5:03 PM, Kevin A. McGrail wrote:
> On 7/25/2012 5:03 AM, Jan Kaluža wrote:
>> With my latest patches [1] mod_perl looks usable to me and there are
>> only few tests which fails. Many of those tests have to be rewritten,
>> because the features they are testing have changed in httpd-2.4.
>
> Jan,
>
> I'm trying to work on testing the patches and extrapolate on your
> work. However, I'm having problems cleanly patching.
>
> If I use http://jkaluza.fedorapeople.org/mod_perl/all.tgz, what
> version of mod_perl should I be patching against?
Following up my own question, it looks like maybe you have some old
patches accidentally included?

These are all dated june 6th and conflict with #'s from june 25th:

0010-Remove-OPT_INCNOEXEC.patch
0011-Fixed-logleve.patch
0012-Use-module-name-in-ap_add_loaded_module.patch
0013-unixd_config-renamed-to-ap_unixd_config.patch
0014-remote_ip-renamed-to-client_ip.patch
0015-remove-apu_error.h-include.patch

I think you might have two sets of patches intermingled.

Regards,
KAM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


jkaluza at redhat

Aug 20, 2012, 10:41 PM

Post #16 of 16 (4104 views)
Permalink
Re: mod_perl and httpd-2.4 - update [In reply to]

On 08/20/2012 11:26 PM, Kevin A. McGrail wrote:
> On 8/20/2012 5:03 PM, Kevin A. McGrail wrote:
>> On 7/25/2012 5:03 AM, Jan Kaluža wrote:
>>> With my latest patches [1] mod_perl looks usable to me and there are
>>> only few tests which fails. Many of those tests have to be rewritten,
>>> because the features they are testing have changed in httpd-2.4.
>>
>> Jan,
>>
>> I'm trying to work on testing the patches and extrapolate on your
>> work. However, I'm having problems cleanly patching.
>>
>> If I use http://jkaluza.fedorapeople.org/mod_perl/all.tgz, what
>> version of mod_perl should I be patching against?
> Following up my own question, it looks like maybe you have some old
> patches accidentally included?

Yes :(, you are right. I've just copied all *.patch files from my
working directory and there were some old ones. Anyway, it's fixed now.
All patches are against mod_perl 2.0.7

> These are all dated june 6th and conflict with #'s from june 25th:
>
> 0010-Remove-OPT_INCNOEXEC.patch
> 0011-Fixed-logleve.patch
> 0012-Use-module-name-in-ap_add_loaded_module.patch
> 0013-unixd_config-renamed-to-ap_unixd_config.patch
> 0014-remote_ip-renamed-to-client_ip.patch
> 0015-remove-apu_error.h-include.patch
>
> I think you might have two sets of patches intermingled.
>
> Regards,
> KAM

Regards,
Jan Kaluza


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

ModPerl dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.