You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2004/04/28 00:52:11 UTC
[Patch mp2] Statically compiling mod_perl in httpd
It's been a long awaited feature, to bring back something similar to the old
mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
at it.
The original way I attempted this was to hook into the new httpd build system,
but, one issue about that is that it would require autoconf/automake/aclocal.
So, instead, this patch tries to make things work by poking at httpd ever so
slightly.
In a nutshell :
$> cd ~
$> tar zxvf httpd-2.0.x.tar.gz
$> cd ~/httpd-2.0.x && ./configure [...]
$> cd ~/mod_perl
$mod_perl> perl Makefile.PL MP_USE_STATIC=1 MP_AP_PREFIX=~/httpd-2.0.x
generating...src/modules/perl/modperl_xsinit.c
mod_perl static library will be built as mod_perl.a
Patching : ~/httpd-2.0.x/build/config_vars.mk
Patching : ~/httpd-2.0.x/modules.c
$mod_perl> make
$mod_perl> cd ~/httpd-2.0.x
$httpd-2.0.x> make
$httpd-2.0.x> ./httpd -l
Compiled in modules:
core.c
[...]
mod_perl.c
$httpd-2.0.x> cd ~/mod_perl
$mod_perl> ./t/TEST -httpd ~/httpd-2.0.x/httpd
$mod_perl> make install
$mod_perl> cd ~/httpd.2.0.x && make install
Statically linking mod_perl should help people on platforms with defective dso
support, for instance.
There is currently one bug with mod_perl compiled statically. It tries to add
the MODPERL2 server define at hook-registry phase, but for statically linked
modules, that hook-registry phase is called before ap_server_config_defines is
created.
The following httpd patch fixes it, and I think it should be submitted to
dev@httpd for inclusion, as what mod_perl is doing is the only way I could find
of adding defines, and it just doesn't work when statically linked. The
pre-config hook doesn't work, because it's being run a bit too late for this:
Index: server/main.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.140.2.8
diff -u -I$Id -r1.140.2.8 main.c
--- server/main.c 30 Mar 2004 20:53:06 -0000 1.140.2.8
+++ server/main.c 27 Apr 2004 22:33:20 -0000
@@ -393,14 +393,13 @@
}
#endif
- ap_setup_prelinked_modules(process);
-
apr_pool_create(&pcommands, pglobal);
apr_pool_tag(pcommands, "pcommands");
ap_server_pre_read_config = apr_array_make(pcommands, 1, sizeof(char *));
ap_server_post_read_config = apr_array_make(pcommands, 1, sizeof(char *));
ap_server_config_defines = apr_array_make(pcommands, 1, sizeof(char *));
+ ap_setup_prelinked_modules(process);
ap_run_rewrite_args(process);
/* Maintain AP_SERVER_BASEARGS list in http_main.h to allow the MPM
And now, the actual static build patch follows; I am aware that it's not
verydefensive and possibly doesn't work on some platforms (win32 anyone?), but I
think it's a step in the good direction. Comments welcome.
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.137
diff -u -I$Id -r1.137 Makefile.PL
--- Makefile.PL 4 Mar 2004 03:36:18 -0000 1.137
+++ Makefile.PL 27 Apr 2004 22:47:37 -0000
@@ -261,6 +261,11 @@
warning "You'll need to add the following to httpd.conf:",
" LoadModule perl_module modules/$build->{MODPERL_LIB_DSO}\n";
}
+
+ #XXX: Not sure this is the best place
+ if ($build->is_static) {
+ $build->patch_httpd_for_static;
+ }
if ($build->{MP_INST_APACHE2}) {
warning "Apache Perl modules will be installed relative to Apache2/";
Index: lib/Apache/Build.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.162
diff -u -I$Id -r1.162 Build.pm
--- lib/Apache/Build.pm 27 Apr 2004 17:26:28 -0000 1.162
+++ lib/Apache/Build.pm 27 Apr 2004 22:47:37 -0000
@@ -87,6 +87,46 @@
return '';
}
+sub patch_httpd_for_static {
+ my $self = shift;
+
+ #AP_LIBS+=
+ my $ldopts = $self->ldopts;
+
+ #XXX: figure the name for all platforms
+ my $lib = catfile($self->{cwd}, qw(src modules perl mod_perl.a));
+
+ my $config_vars = catfile($self->dir, qw(build config_vars.mk));
+
+ warning "Patching : $config_vars";
+ {
+ local @ARGV = $config_vars;
+ local $^I = ".bak";
+ while (<>) {
+ s/^AP_LIBS\s*=(.*)/AP_LIBS=$1 $ldopts/;
+ s/^BUILTIN_LIBS\s*=(.*)/BUILTIN_LIBS=$1 $lib/;
+ print;
+ }
+ unlink $config_vars . $^I;
+ }
+
+ my $modules = catfile($self->dir, qw(modules.c));
+
+ warning "Patching : $modules";
+
+ my $fh;
+ open($fh, "<$modules");
+ local $/ = undef;
+ my $modules_data = <$fh>;
+ $modules_data =~
+ s/(extern module core_module;)/$1\nextern module perl_module;/;
+ $modules_data =~ s/(\s*)NULL/$1&perl_module,$1NULL/g;
+ close($fh);
+ open($fh, ">$modules");
+ print $fh $modules_data;
+ close($fh);
+}
+
sub httpd_is_source_tree {
my $self = shift;
@@ -796,6 +836,7 @@
#--- attribute access ---
sub is_dynamic { shift->{MP_USE_DSO} }
+sub is_static { shift->{MP_USE_STATIC} }
sub default_dir {
my $build = shift->build_config;
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
>
> Geoffrey Young wrote:
>>>There is currently one bug with mod_perl compiled statically. It tries to add
>>>the MODPERL2 server define at hook-registry phase, but for statically linked
>>>modules, that hook-registry phase is called before ap_server_config_defines is
>>>created.
>>
>>
>>hmm, called before, or the dso reload behavior is different so we don't
>>notice with dso? I wasn't aware that the order of things actually changed
>>with dso vs static.
>>
>
>
> Basically, we want to define MODPERL2 as a server define, and the only phase
> where you can safely do that before configuration is during the hook-registry
> phase. the pre_config hook is not early enough for this.
>
> So, from httpd/server/main.c:
>
> ap_setup_prelinked_modules(process);
> [...]
> ap_server_config_defines = apr_array_make(pcommands, 1, sizeof(char *));
>
> And the problem is that ap_setup_prelinked_modules() loads up static modules
> about the same way that mod_so does it, just at a much earlier time.
> ap_setup_prelinked_modules() calls register_hooks on mod_perl (and the other
> statically compiled modules), and mod_perl's register_hooks tries to push
> MODPERL2 to ap_server_config_defines, but that's not initialized yet, so SEGV.
>
> It can be fixed either with my simple httpd patch, or possibly by introducing an
> httpd API to manipulate ap_server_config_defines that can create it when first
> accessed.
Why do you need a new API? I think the best fix is to have
ap_server_config_defines call the array_make if pcommands is NULL, or is it a
static var unaccessible from ap_server_config_defines? I haven't looked at the
source.
> But the patch I suggested just moves static module initialization after a few
> global structures have been initialized, so I can't see what harm it could do.
And someone later will decide to move it back, breaking things again. Allocate
on demand is probably the cleanest solution.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Basically, we want to define MODPERL2 as a server define, and the only phase
> where you can safely do that before configuration is during the hook-registry
> phase. the pre_config hook is not early enough for this.
why isn't pre_config early enough? because of the ap_read_config call?
>
> But the patch I suggested just moves static module initialization after a few
> global structures have been initialized, so I can't see what harm it could do.
ok, I've looked at the code and I get it now. I think your patch ought to
be ok, but I think stas has a point in his other mail. nevertheless, this
discussion really belongs on httpd-dev at this point.
so, I'd suggest submitting the patch to httpd-dev and we can follow up on it
there. just don't forget to re-diff against httpd HEAD, as your current
patch looks to be against APACHE_2_0_BRANCH. and don't forget to not
mention mod_perl ;)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Geoffrey Young wrote:
>
> Philippe M. Chiasson wrote:
>
>>It's been a long awaited feature, to bring back something similar to the old
>>mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
>>at it.
>
>
> whee!
This patch sure needs a bit of polishing, but yes, it was long due...
>
>>There is currently one bug with mod_perl compiled statically. It tries to add
>>the MODPERL2 server define at hook-registry phase, but for statically linked
>>modules, that hook-registry phase is called before ap_server_config_defines is
>>created.
>
>
> hmm, called before, or the dso reload behavior is different so we don't
> notice with dso? I wasn't aware that the order of things actually changed
> with dso vs static.
>
Basically, we want to define MODPERL2 as a server define, and the only phase
where you can safely do that before configuration is during the hook-registry
phase. the pre_config hook is not early enough for this.
So, from httpd/server/main.c:
ap_setup_prelinked_modules(process);
[...]
ap_server_config_defines = apr_array_make(pcommands, 1, sizeof(char *));
And the problem is that ap_setup_prelinked_modules() loads up static modules
about the same way that mod_so does it, just at a much earlier time.
ap_setup_prelinked_modules() calls register_hooks on mod_perl (and the other
statically compiled modules), and mod_perl's register_hooks tries to push
MODPERL2 to ap_server_config_defines, but that's not initialized yet, so SEGV.
It can be fixed either with my simple httpd patch, or possibly by introducing an
httpd API to manipulate ap_server_config_defines that can create it when first
accessed.
But the patch I suggested just moves static module initialization after a few
global structures have been initialized, so I can't see what harm it could do.
>>The following httpd patch fixes it, and I think it should be submitted to
>>dev@httpd for inclusion, as what mod_perl is doing is the only way I could find
>>of adding defines, and it just doesn't work when statically linked.
>
>
> hmm, can you expand on this a bit more. clearly mod_perl isn't the only one
> who needs to link both statically and dynamically, so is it that mod_perl is
> doing something other core modules (like, say, dav) are not?
Yup, we try to apr_array_push() to a not yet created ap_server_config_defines
> I'd be happy to shepherd whatever needs to be done with httpd, I just need
> to understand it well enough to defend it or offer alternatives when people
> over there say httpd is all well and fine. so, more specific code pointers
> would be much appreciated.
>
> --Geoff
>
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Philippe M. Chiasson wrote:
> It's been a long awaited feature, to bring back something similar to the old
> mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
> at it.
whee!
> There is currently one bug with mod_perl compiled statically. It tries to add
> the MODPERL2 server define at hook-registry phase, but for statically linked
> modules, that hook-registry phase is called before ap_server_config_defines is
> created.
hmm, called before, or the dso reload behavior is different so we don't
notice with dso? I wasn't aware that the order of things actually changed
with dso vs static.
>
> The following httpd patch fixes it, and I think it should be submitted to
> dev@httpd for inclusion, as what mod_perl is doing is the only way I could find
> of adding defines, and it just doesn't work when statically linked.
hmm, can you expand on this a bit more. clearly mod_perl isn't the only one
who needs to link both statically and dynamically, so is it that mod_perl is
doing something other core modules (like, say, dav) are not?
I'd be happy to shepherd whatever needs to be done with httpd, I just need
to understand it well enough to defend it or offer alternatives when people
over there say httpd is all well and fine. so, more specific code pointers
would be much appreciated.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>
>> Stas Bekman wrote:
>>
>>>>>>> If I remember correctly there were too many problems with that
>>>>>>> approach. And if that's the case. We may need to first install
>>>>>>> httpd, then test modperl and then install modperl. If there are
>>>>>>> no problems, then modperl's make install should install httpd as
>>>>>>> well, as it did in mp1 (plus note my question above regarding
>>>>>>> the flexible build).
>>>>>>
>>>>>>
>>>>>>
>>>>>> So mod_perl's make test (or make) should install httpd then ?
>>>>>
>>>>>
>>>>>
>>>>> let's try first if we can test w/o installing.
>>>>
>>>>
>>>>
>>>> Well, I just managed to run most tests w/o installing against the
>>>> httpd
>>>> in the srcdir ;-)
>>>
>>>
>>>
>>> How bad were the failures? Is it going to be too much of hassle to
>>> support that?
>>
>>
>>
>> There seem to be only 2 problems:
>>
>> t/apr/finfo.t 255 65280 ?? ?? % ??
>> [Thu May 06 16:08:07 2004] [error] [client 127.0.0.1] Use of
>> uninitialized value
>> in pattern match (m//) at
>> mod_perl/2.0/cvs/Apache-Test/lib/Apache/Test.pm line 399.
>> BEGIN failed--compilation aborted at
>> mod_perl/2.0/cvs/t/response/TestAPR/finfo.pm line 13.
>> Compilation failed in require at (eval 96) line 3.
>>
>> t/apr/flatten.t ?? ?? % ??
>> [Thu May 06 16:09:04 2004] [error] server reached MaxClients setting,
>> consider
>> raising the MaxClients setting
>> lt-httpd: error while loading shared libraries:
>> mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
>> modperl_bucket_sv_create
>
>
> Heh, you definitely have missed the thread of your first user who did
> the static build, who had exactly the same problems.
> http://marc.theaimsgroup.com/?t=108325310800002&r=1&w=2
Yeah, I just found out about it when looking for the cause of this problem.
> Olivier has fixed it by linking APR::Bucket statically. I'm glad that
> you have them too, may be you will figure out what's wrong with it.
Yes, it worked fine for me, but there is definitely an underlying
problem that needs to get fixed.
> __________________________________________________________________
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
>
> Stas Bekman wrote:
>
>>>>>>If I remember
>>>>>>correctly there were too many problems with that approach. And if that's the
>>>>>>case. We may need to first install httpd, then test modperl and then install
>>>>>>modperl. If there are no problems, then modperl's make install should install
>>>>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>>>>flexible build).
>>>>>
>>>>>
>>>>>So mod_perl's make test (or make) should install httpd then ?
>>>>
>>>>
>>>>let's try first if we can test w/o installing.
>>>
>>>
>>>Well, I just managed to run most tests w/o installing against the httpd
>>>in the srcdir ;-)
>>
>>
>>How bad were the failures? Is it going to be too much of hassle to support that?
>
>
> There seem to be only 2 problems:
>
> t/apr/finfo.t 255 65280 ?? ?? % ??
> [Thu May 06 16:08:07 2004] [error] [client 127.0.0.1] Use of uninitialized value
> in pattern match (m//) at mod_perl/2.0/cvs/Apache-Test/lib/Apache/Test.pm line 399.
> BEGIN failed--compilation aborted at
> mod_perl/2.0/cvs/t/response/TestAPR/finfo.pm line 13.
> Compilation failed in require at (eval 96) line 3.
>
> t/apr/flatten.t ?? ?? % ??
> [Thu May 06 16:09:04 2004] [error] server reached MaxClients setting, consider
> raising the MaxClients setting
> lt-httpd: error while loading shared libraries:
> mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
> modperl_bucket_sv_create
Heh, you definitely have missed the thread of your first user who did the
static build, who had exactly the same problems.
http://marc.theaimsgroup.com/?t=108325310800002&r=1&w=2
Olivier has fixed it by linking APR::Bucket statically. I'm glad that you have
them too, may be you will figure out what's wrong with it.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
>>>>>If I remember
>>>>>correctly there were too many problems with that approach. And if that's the
>>>>>case. We may need to first install httpd, then test modperl and then install
>>>>>modperl. If there are no problems, then modperl's make install should install
>>>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>>>flexible build).
>>>>
>>>>
>>>>So mod_perl's make test (or make) should install httpd then ?
>>>
>>>
>>>let's try first if we can test w/o installing.
>>
>>
>>Well, I just managed to run most tests w/o installing against the httpd
>>in the srcdir ;-)
>
>
> How bad were the failures? Is it going to be too much of hassle to support that?
There seem to be only 2 problems:
t/apr/finfo.t 255 65280 ?? ?? % ??
[Thu May 06 16:08:07 2004] [error] [client 127.0.0.1] Use of uninitialized value
in pattern match (m//) at mod_perl/2.0/cvs/Apache-Test/lib/Apache/Test.pm line 399.
BEGIN failed--compilation aborted at
mod_perl/2.0/cvs/t/response/TestAPR/finfo.pm line 13.
Compilation failed in require at (eval 96) line 3.
t/apr/flatten.t ?? ?? % ??
[Thu May 06 16:09:04 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_body.t 255 65280 2 4 200.00% 1-2
[Thu May 06 16:10:34 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_consume.t 1 1 100.00% 1
[Thu May 06 16:11:30 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_inject_header.t 255 65280 36 72 200.00% 1-36
[Thu May 06 16:12:24 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_msg.t 255 65280 ?? ?? % ??
[Thu May 06 16:13:33 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_underrun.t 1 1 100.00% 1
[Thu May 06 16:14:32 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/out_bbs_basic.t 255 65280 ?? ?? % ??
[Thu May 06 16:19:37 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/out_bbs_ctx.t 1 1 100.00% 1
[Thu May 06 16:22:01 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
>
> [...]
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
>>>>If I remember
>>>>correctly there were too many problems with that approach. And if that's the
>>>>case. We may need to first install httpd, then test modperl and then install
>>>>modperl. If there are no problems, then modperl's make install should install
>>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>>flexible build).
>>>
>>>
>>>So mod_perl's make test (or make) should install httpd then ?
>>
>>
>>let's try first if we can test w/o installing.
>
>
> Well, I just managed to run most tests w/o installing against the httpd
> in the srcdir ;-)
How bad were the failures? Is it going to be too much of hassle to support that?
>>>>If we go with 'make test' against the source, then it's easy - we know the
>>>>location of the source dir and we know the relative location of httpd
>>>>executable. So just set -httpd /path/to/httpd from Makefile.PL, before
>>>>creating t/TEST. Actually I think that we already handle that case internally
>>>>(at least we did when we tried to make 'make test' work against the source).
>>>
>>>
>>>Yes, that's what I thought, but I couldn't find where that magic is hapenning.
>>>Care to point out to me, as it was the solution I wanted to try. I did it
>>>manually just now and it does work and most test passe fine.
>>
>>
>>It's the filter_args sub that does the magic. So you do:
>>
>> @ARGV, qw(-httpd /path/to/httpd);
>> Apache::TestMM::filter_args();
>>
>>before calling
>>
>> ModPerl::TestRun->generate_script;
>>
>>or you can populate:
>>
>> @Apache::TestMM::Argv = qw(-httpd /path/to/httpd);
>>
>>instead of calling filter_args.
>
>
> I just tried that and the problem is messier. The Makefile uses PASSENV
> and always ends up invoking t/TEST as
>
> APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER=
> APACHE_TEST_APXS= perl t/TEST
>
> and the environment vars seems to have precedence over whatever is in t/TEST
> so the test still fails.
>
> Running ./t/TEST manually does work now though ;-)
Something is wrong then. I've explicitly coded it to ignore any env vars if
they are empty, precisely for this purpose. There must be a bug then. Look at
Test.run:
sub custom_config_add_conf_opts {
my $args = shift;
...
for (@data_vars_opt) {
next unless $Apache::TestConfigData::vars->{$_};
# env vars override custom config
my $env_value = $ENV{ $vars_to_env{$_} };
next unless defined $env_value and length $env_value;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
$args->{$_} ||= $Apache::TestConfigData::vars->{$_};
}
}
>>>>If we go with 'make test' against the post-install httpd, then we have no idea
>>>>what's the location, besides snooping on some httpd config files or using apxs
>>>>if available. i.e. apachectl knows where httpd is located, so we should look
>>>>at how apachectl finds it out and do the same.
>>>>
>>>
>>>
>>>And unless I am wrong, there should be an apxs in the build directory that knows
>>>about httpd's to-be installed PREFIX
>>
>>
>>But apxs doesn't work for static builds, does it? At least it doesn't in
>>apache1.3. I haven't tried in apache2.
>>
>>
>>
>>>>>+ if ($build->do_httpd) {
>>>>
>>>>
>>>>can this be $build->should_configure_httpd?
>>>
>>>
>>>It can very well be anything you want ;-)
>>
>>
>>perfect :)
>
>
> Actually, how about should_build_httpd ?
That's fine.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
>>>Should we think right away about how to do the flexible build, ala mp1? So one
>>>can link httpd statically with mod_perl and other 3rd party modules which
>>>require a separate build (php?). Or should we handle that one later?
>>
>>
>>I'd put that one to a bit later, as things in httpd-2.0 land aren't as easy
>>to configure around. The only way to trick httpd's ./configure to build mod_perl
>>is by using a specific set of environment variables at configuration time.
>>
>>Allowing for a more flexible build like mp1 used to offer will be a bit more
>>complicated without having users cut-n-paste a few environment vars.
>
> >
>
>>For now, I'd leave it at this, and possibly document how to build something
>>like php with it.
>
>
> +1, your change is pretty small, so it's not like we will need to change many
> things to support the flexible build.
>
>
>>In the meantime, I've been looking at a single possible new feature for httpd's
>>./configure that would allow for an even cleaner build and allow 3rd party
>>builds to be possible to
>>
>>$> cd httpd
>>$> ./configure --enable-module=perl:../mod_perl/src/module/perl/mod_perl.a
>>$> cd mod_perl && make
>>$> cd httpd && make
>>
>>But currently, the --enable-module= syntax of httpd isn't quite flexible
>>enough.
>
>
> I'd suggest to look at how php does that?
Will look at it.
>
>
>>>If I remember
>>>correctly there were too many problems with that approach. And if that's the
>>>case. We may need to first install httpd, then test modperl and then install
>>>modperl. If there are no problems, then modperl's make install should install
>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>flexible build).
>>
>>
>>So mod_perl's make test (or make) should install httpd then ?
>
>
> let's try first if we can test w/o installing.
Well, I just managed to run most tests w/o installing against the httpd
in the srcdir ;-)
> If not, then yes, it should install it first. In which case we may want to
> make user do that, since they will want to become root.
Yup.
>
>>>If we go with 'make test' against the source, then it's easy - we know the
>>>location of the source dir and we know the relative location of httpd
>>>executable. So just set -httpd /path/to/httpd from Makefile.PL, before
>>>creating t/TEST. Actually I think that we already handle that case internally
>>>(at least we did when we tried to make 'make test' work against the source).
>>
>>
>>Yes, that's what I thought, but I couldn't find where that magic is hapenning.
>>Care to point out to me, as it was the solution I wanted to try. I did it
>>manually just now and it does work and most test passe fine.
>
>
> It's the filter_args sub that does the magic. So you do:
>
> @ARGV, qw(-httpd /path/to/httpd);
> Apache::TestMM::filter_args();
>
> before calling
>
> ModPerl::TestRun->generate_script;
>
> or you can populate:
>
> @Apache::TestMM::Argv = qw(-httpd /path/to/httpd);
>
> instead of calling filter_args.
I just tried that and the problem is messier. The Makefile uses PASSENV
and always ends up invoking t/TEST as
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER=
APACHE_TEST_APXS= perl t/TEST
and the environment vars seems to have precedence over whatever is in t/TEST
so the test still fails.
Running ./t/TEST manually does work now though ;-)
>
>>>If we go with 'make test' against the post-install httpd, then we have no idea
>>>what's the location, besides snooping on some httpd config files or using apxs
>>>if available. i.e. apachectl knows where httpd is located, so we should look
>>>at how apachectl finds it out and do the same.
>>>
>>
>>
>>And unless I am wrong, there should be an apxs in the build directory that knows
>>about httpd's to-be installed PREFIX
>
>
> But apxs doesn't work for static builds, does it? At least it doesn't in
> apache1.3. I haven't tried in apache2.
>
>
>>>>+ if ($build->do_httpd) {
>>>
>>>
>>>can this be $build->should_configure_httpd?
>>
>>
>>It can very well be anything you want ;-)
>
>
> perfect :)
Actually, how about should_build_httpd ?
>
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
>>Should we think right away about how to do the flexible build, ala mp1? So one
>>can link httpd statically with mod_perl and other 3rd party modules which
>>require a separate build (php?). Or should we handle that one later?
>
>
> I'd put that one to a bit later, as things in httpd-2.0 land aren't as easy
> to configure around. The only way to trick httpd's ./configure to build mod_perl
> is by using a specific set of environment variables at configuration time.
>
> Allowing for a more flexible build like mp1 used to offer will be a bit more
> complicated without having users cut-n-paste a few environment vars.
>
> For now, I'd leave it at this, and possibly document how to build something
> like php with it.
+1, your change is pretty small, so it's not like we will need to change many
things to support the flexible build.
> In the meantime, I've been looking at a single possible new feature for httpd's
> ./configure that would allow for an even cleaner build and allow 3rd party
> builds to be possible to
>
> $> cd httpd
> $> ./configure --enable-module=perl:../mod_perl/src/module/perl/mod_perl.a
> $> cd mod_perl && make
> $> cd httpd && make
>
> But currently, the --enable-module= syntax of httpd isn't quite flexible
> enough.
I'd suggest to look at how php does that?
>>If I remember
>>correctly there were too many problems with that approach. And if that's the
>>case. We may need to first install httpd, then test modperl and then install
>>modperl. If there are no problems, then modperl's make install should install
>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>flexible build).
>
>
> So mod_perl's make test (or make) should install httpd then ?
let's try first if we can test w/o installing.
If not, then yes, it should install it first. In which case we may want to
make user do that, since they will want to become root.
>>If we go with 'make test' against the source, then it's easy - we know the
>>location of the source dir and we know the relative location of httpd
>>executable. So just set -httpd /path/to/httpd from Makefile.PL, before
>>creating t/TEST. Actually I think that we already handle that case internally
>>(at least we did when we tried to make 'make test' work against the source).
>
>
> Yes, that's what I thought, but I couldn't find where that magic is hapenning.
> Care to point out to me, as it was the solution I wanted to try. I did it
> manually just now and it does work and most test passe fine.
It's the filter_args sub that does the magic. So you do:
@ARGV, qw(-httpd /path/to/httpd);
Apache::TestMM::filter_args();
before calling
ModPerl::TestRun->generate_script;
or you can populate:
@Apache::TestMM::Argv = qw(-httpd /path/to/httpd);
instead of calling filter_args.
>>If we go with 'make test' against the post-install httpd, then we have no idea
>>what's the location, besides snooping on some httpd config files or using apxs
>>if available. i.e. apachectl knows where httpd is located, so we should look
>>at how apachectl finds it out and do the same.
>>
>
>
> And unless I am wrong, there should be an apxs in the build directory that knows
> about httpd's to-be installed PREFIX
But apxs doesn't work for static builds, does it? At least it doesn't in
apache1.3. I haven't tried in apache2.
>>>+ if ($build->do_httpd) {
>>
>>
>>can this be $build->should_configure_httpd?
>
>
> It can very well be anything you want ;-)
perfect :)
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>After thinkering about all the problems with my initial solutions
>>and looking a bit more closely at httpd's build system, I've come
>>up with a solution that doesn't involve any patching.
>>
>>It would be used like this
>>
>>$> perl Makefile.PL \
>> MP_USE_STATIC=1 \
>> MP_AP_CONFIGURE="--with-mpm=prefork --enable-debug [...]"
>>$> make
>>
>>The Makefile.PL runs httpd's ./configure and enables mod_perl
>>The make command will build httpd first and then mod_perl (a required
>>order)
>
>
> Excellent. That's very much like mp1 did it.
Yes indeed.
> Should we think right away about how to do the flexible build, ala mp1? So one
> can link httpd statically with mod_perl and other 3rd party modules which
> require a separate build (php?). Or should we handle that one later?
I'd put that one to a bit later, as things in httpd-2.0 land aren't as easy
to configure around. The only way to trick httpd's ./configure to build mod_perl
is by using a specific set of environment variables at configuration time.
Allowing for a more flexible build like mp1 used to offer will be a bit more
complicated without having users cut-n-paste a few environment vars.
For now, I'd leave it at this, and possibly document how to build something
like php with it.
In the meantime, I've been looking at a single possible new feature for httpd's
./configure that would allow for an even cleaner build and allow 3rd party
builds to be possible to
$> cd httpd
$> ./configure --enable-module=perl:../mod_perl/src/module/perl/mod_perl.a
$> cd mod_perl && make
$> cd httpd && make
But currently, the --enable-module= syntax of httpd isn't quite flexible
enough.
>
>>There are 2 small issues left that I can think of.
>>
>>First, should make install also install httpd ? Or maybe use another
>>configurable option MP_AP_INSTALL=1 to control it
>>
>>Second, right now, make test will only work if called like
>>
>>$> make test APACHE_TEST_HTTPD=/path/to/httpd/src/httpd
>>
>>I can't figure out how to pass this httpd location to t/TEST at
>>configure time to avoid this. Stas ?
>
>
> I guess the two are somewhat related. It has been ages since I last tried to
> test against uninstalled httpd. Does it still work at all?
No idea.
> If I remember
> correctly there were too many problems with that approach. And if that's the
> case. We may need to first install httpd, then test modperl and then install
> modperl. If there are no problems, then modperl's make install should install
> httpd as well, as it did in mp1 (plus note my question above regarding the
> flexible build).
So mod_perl's make test (or make) should install httpd then ?
> If we go with 'make test' against the source, then it's easy - we know the
> location of the source dir and we know the relative location of httpd
> executable. So just set -httpd /path/to/httpd from Makefile.PL, before
> creating t/TEST. Actually I think that we already handle that case internally
> (at least we did when we tried to make 'make test' work against the source).
Yes, that's what I thought, but I couldn't find where that magic is hapenning.
Care to point out to me, as it was the solution I wanted to try. I did it
manually just now and it does work and most test passe fine.
> If we go with 'make test' against the post-install httpd, then we have no idea
> what's the location, besides snooping on some httpd config files or using apxs
> if available. i.e. apachectl knows where httpd is located, so we should look
> at how apachectl finds it out and do the same.
>
And unless I am wrong, there should be an apxs in the build directory that knows
about httpd's to-be installed PREFIX
>>+ if ($build->do_httpd) {
>
>
> can this be $build->should_configure_httpd?
It can very well be anything you want ;-)
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> After thinkering about all the problems with my initial solutions
> and looking a bit more closely at httpd's build system, I've come
> up with a solution that doesn't involve any patching.
>
> It would be used like this
>
> $> perl Makefile.PL \
> MP_USE_STATIC=1 \
> MP_AP_CONFIGURE="--with-mpm=prefork --enable-debug [...]"
> $> make
>
> The Makefile.PL runs httpd's ./configure and enables mod_perl
> The make command will build httpd first and then mod_perl (a required
> order)
Excellent. That's very much like mp1 did it.
Should we think right away about how to do the flexible build, ala mp1? So one
can link httpd statically with mod_perl and other 3rd party modules which
require a separate build (php?). Or should we handle that one later?
> There are 2 small issues left that I can think of.
>
> First, should make install also install httpd ? Or maybe use another
> configurable option MP_AP_INSTALL=1 to control it
>
> Second, right now, make test will only work if called like
>
> $> make test APACHE_TEST_HTTPD=/path/to/httpd/src/httpd
>
> I can't figure out how to pass this httpd location to t/TEST at
> configure time to avoid this. Stas ?
I guess the two are somewhat related. It has been ages since I last tried to
test against uninstalled httpd. Does it still work at all? If I remember
correctly there were too many problems with that approach. And if that's the
case. We may need to first install httpd, then test modperl and then install
modperl. If there are no problems, then modperl's make install should install
httpd as well, as it did in mp1 (plus note my question above regarding the
flexible build).
If we go with 'make test' against the source, then it's easy - we know the
location of the source dir and we know the relative location of httpd
executable. So just set -httpd /path/to/httpd from Makefile.PL, before
creating t/TEST. Actually I think that we already handle that case internally
(at least we did when we tried to make 'make test' work against the source).
If we go with 'make test' against the post-install httpd, then we have no idea
what's the location, besides snooping on some httpd config files or using apxs
if available. i.e. apachectl knows where httpd is located, so we should look
at how apachectl finds it out and do the same.
> + if ($build->do_httpd) {
can this be $build->should_configure_httpd?
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
After thinkering about all the problems with my initial solutions
and looking a bit more closely at httpd's build system, I've come
up with a solution that doesn't involve any patching.
It would be used like this
$> perl Makefile.PL \
MP_USE_STATIC=1 \
MP_AP_CONFIGURE="--with-mpm=prefork --enable-debug [...]"
$> make
The Makefile.PL runs httpd's ./configure and enables mod_perl
The make command will build httpd first and then mod_perl (a required
order)
There are 2 small issues left that I can think of.
First, should make install also install httpd ? Or maybe use another
configurable option MP_AP_INSTALL=1 to control it
Second, right now, make test will only work if called like
$> make test APACHE_TEST_HTTPD=/path/to/httpd/src/httpd
I can't figure out how to pass this httpd location to t/TEST at
configure time to avoid this. Stas ?
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.137
diff -u -I$Id -r1.137 Makefile.PL
--- Makefile.PL 4 Mar 2004 03:36:18 -0000 1.137
+++ Makefile.PL 6 May 2004 18:43:25 -0000
@@ -225,6 +225,10 @@
#ModPerl::BuildMM will use Apache::BuildConfig in subdir/Makefile.PL's
$build->save;
+ if ($build->do_httpd) {
+ $build->configure_httpd();
+ }
+
ModPerl::TestRun->generate_script;
ModPerl::TestReport->generate_script;
Apache::TestSmokePerl->generate_script;
@@ -460,6 +464,11 @@
my $self = shift;
my $string = $self->ModPerl::BuildMM::MY::top_targets;
+ if ($build->do_httpd) {
+ ModPerl::MM::add_dep(\$string, pure_all => 'do_httpd');
+ $string .= qq[\ndo_httpd:\n\tcd "$build->{MP_AP_PREFIX}" && make\n];
+ }
+
ModPerl::MM::add_dep(\$string, pure_all => 'modperl_lib');
$string .= <<'EOF';
Index: lib/Apache/Build.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.162
diff -u -I$Id -r1.162 Build.pm
--- lib/Apache/Build.pm 27 Apr 2004 17:26:28 -0000 1.162
+++ lib/Apache/Build.pm 6 May 2004 18:43:25 -0000
@@ -244,6 +244,33 @@
return $self->{mpm_name} = $mpm_name;
}
+sub do_httpd {
+ my ($self) = @_;
+ return $self->{MP_AP_CONFIGURE} ? 1 : 0;
+}
+
+sub configure_httpd {
+ my ($self) = @_;
+
+ debug "Configuring httpd in $self->{MP_AP_PREFIX}";
+
+ my $mplib = "$self->{MP_LIBNAME}$Config{lib_ext}";
+ my $mplibpath = catfile($self->{cwd}, qw(src modules perl), $mplib);
+
+ local $ENV{BUILTIN_LIBS} = $mplibpath;
+ local $ENV{AP_LIBS} = $self->ldopts;
+ local $ENV{MODLIST} = 'perl';
+
+ #XXX: -Wall and/or -Werror at httpd configure time breaks things
+ local $ENV{CFLAGS} = join ' ', grep { ! /\-Wall|\-Werror/ }
+ split /\s+/, $ENV{CFLAGS};
+
+ my $cd = qq(cd $self->{MP_AP_PREFIX});
+ my $cmd = qq(./configure $self->{MP_AP_CONFIGURE});
+ debug "Running $cmd";
+ system("$cd && $cmd") == 0 or die "httpd: $cmd failed";
+}
+
#--- Perl Config stuff ---
my %gtop_config = ();
Index: lib/ModPerl/BuildOptions.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
retrieving revision 1.26
diff -u -I$Id -r1.26 BuildOptions.pm
--- lib/ModPerl/BuildOptions.pm 4 Mar 2004 06:01:06 -0000 1.26
+++ lib/ModPerl/BuildOptions.pm 6 May 2004 18:43:25 -0000
@@ -220,6 +220,7 @@
STATIC_EXTS 0 Build Apache::*.xs as static extensions
APXS 0 Path to apxs
AP_PREFIX 0 Apache installation or source tree prefix
+AP_CONFIGURE 0 Apache ./configure arguments
APR_CONFIG 0 Path to apr-config
XS_GLUE_DIR 1 Directories containing extension glue
INCLUDE_DIR 1 Add directories to search for header files
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
>
> Stas Bekman wrote:
>
>>Philippe M. Chiasson wrote:
>>
>>
>>>It's been a long awaited feature, to bring back something similar to the old
>>>mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
>>>at it.
>>
>>
>>You rock, this looks so simple :)
>>
>>
>>
>>>The original way I attempted this was to hook into the new httpd build system,
>>>but, one issue about that is that it would require autoconf/automake/aclocal.
>>>
>>>So, instead, this patch tries to make things work by poking at httpd ever so
>>>slightly.
>>
>>
>>I doubt patching is the best route. Or at least we should support both ways -
>>e.g. if there is autoconf/automake/aclocal then use that, otherwise use
>>patching?
>
>
> Well, that's certainly possible to support both, any good suggestions on a
> Makefile.PL option name ? MP_PATCH_HTTPD vs MP_AUTOCONF_HTTPD ?
>
> But if you look at it, the patching really only changes a few build options that
> can't easily be modified by command-line options (and adds mod_perl to the list
> of static modules the hard way)
Before we proceed, I'd really like to see a solution not involving the patch.
There are many bad side effects to it. A few to mention: If you are working
against cvs, you will get the httpd source changed and it'll get on the way
all the time. If you attempt to run the install twice you will attempt to
patch it twice. And probably other reasons against it too.
>>I guess autoconf staff is a lot of stuff to write?
>
>
> Not hard at all, actually. If we are willing to require a re-run of
> autoconf/automake etc, it's quite simple.
See below.
>>BTW, libapreq2
>>added static linking recently, have you looked at how it performs that? (I
>>haven't yet).
>
>
> Just looked at it, and it's basically doing the same thing I am doing, except
> one thing, it runs httpd's ./configure on behalf of the user, in mod_perl land,
> that would translate to:
>
> perl Makefile.PL MP_USE_STATIC=1 MP_CONFIGURE_HTTPD=1 MP_AP_PREFIX=../src/httpd
> MP_CONFIGURE_HTTPD_ARGS="--with-mpm=worker --enable-module=status [...]"
So it doesn't do any patching, right? What prevents us from doing the same?
>>>There is currently one bug with mod_perl compiled statically. It tries to add
>>>the MODPERL2 server define at hook-registry phase, but for statically linked
>>>modules, that hook-registry phase is called before ap_server_config_defines is
>>>created.
>>
>>
>>so may be we can dynamically add some hook to insert the define at a later time?
>
>
> Sadly, not possible right now. the problem is that :
>
> 1. server/main() calls ap_setup_prelinked_modules which calls register_hooks
> 2. server_conf = ap_read_config(process, ptemp, confname, &ap_conftree);
> 3 server/main() calls pre_config
>
> And #3 is too late to add to the defines, because they are prossed early on in
> #2, so the only possible time to push to that array is sadly in #1
OK, thanks.
>>The patch looks fine to me, but if it makes it in static build will require
>>2.0.50?
>
>
> And that's not very nice. Another possibility (not a big fan) is that since we
> are patching/configuring httpd anyways, maybe we can just move
> ap_setup_prelinked_modules down (as my patch did) ourselves if httpd < 2.0.50...
But we don't want the Apache source patching if we can avoid it. I see no
problem with requiring 2.0.50 for the static build, since most people won't
need it. And hopefully 2.0.50 will get released soon.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>It's been a long awaited feature, to bring back something similar to the old
>>mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
>>at it.
>
>
> You rock, this looks so simple :)
>
>
>>The original way I attempted this was to hook into the new httpd build system,
>>but, one issue about that is that it would require autoconf/automake/aclocal.
>>
>>So, instead, this patch tries to make things work by poking at httpd ever so
>>slightly.
>
>
> I doubt patching is the best route. Or at least we should support both ways -
> e.g. if there is autoconf/automake/aclocal then use that, otherwise use
> patching?
Well, that's certainly possible to support both, any good suggestions on a
Makefile.PL option name ? MP_PATCH_HTTPD vs MP_AUTOCONF_HTTPD ?
But if you look at it, the patching really only changes a few build options that
can't easily be modified by command-line options (and adds mod_perl to the list
of static modules the hard way)
> I guess autoconf staff is a lot of stuff to write?
Not hard at all, actually. If we are willing to require a re-run of
autoconf/automake etc, it's quite simple.
> BTW, libapreq2
> added static linking recently, have you looked at how it performs that? (I
> haven't yet).
Just looked at it, and it's basically doing the same thing I am doing, except
one thing, it runs httpd's ./configure on behalf of the user, in mod_perl land,
that would translate to:
perl Makefile.PL MP_USE_STATIC=1 MP_CONFIGURE_HTTPD=1 MP_AP_PREFIX=../src/httpd
MP_CONFIGURE_HTTPD_ARGS="--with-mpm=worker --enable-module=status [...]"
>
>>There is currently one bug with mod_perl compiled statically. It tries to add
>>the MODPERL2 server define at hook-registry phase, but for statically linked
>>modules, that hook-registry phase is called before ap_server_config_defines is
>>created.
>
>
> so may be we can dynamically add some hook to insert the define at a later time?
Sadly, not possible right now. the problem is that :
1. server/main() calls ap_setup_prelinked_modules which calls register_hooks
2. server_conf = ap_read_config(process, ptemp, confname, &ap_conftree);
3 server/main() calls pre_config
And #3 is too late to add to the defines, because they are prossed early on in
#2, so the only possible time to push to that array is sadly in #1
> The patch looks fine to me, but if it makes it in static build will require
> 2.0.50?
And that's not very nice. Another possibility (not a big fan) is that since we
are patching/configuring httpd anyways, maybe we can just move
ap_setup_prelinked_modules down (as my patch did) ourselves if httpd < 2.0.50...
> __________________________________________________________________
> 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
>
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: [Patch mp2] Statically compiling mod_perl in httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> It's been a long awaited feature, to bring back something similar to the old
> mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
> at it.
You rock, this looks so simple :)
> The original way I attempted this was to hook into the new httpd build system,
> but, one issue about that is that it would require autoconf/automake/aclocal.
>
> So, instead, this patch tries to make things work by poking at httpd ever so
> slightly.
I doubt patching is the best route. Or at least we should support both ways -
e.g. if there is autoconf/automake/aclocal then use that, otherwise use
patching? I guess autoconf staff is a lot of stuff to write? BTW, libapreq2
added static linking recently, have you looked at how it performs that? (I
haven't yet).
> There is currently one bug with mod_perl compiled statically. It tries to add
> the MODPERL2 server define at hook-registry phase, but for statically linked
> modules, that hook-registry phase is called before ap_server_config_defines is
> created.
so may be we can dynamically add some hook to insert the define at a later time?
The patch looks fine to me, but if it makes it in static build will require
2.0.50?
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org