You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Marcin Kasperski <Ma...@acn.waw.pl> on 2002/12/01 23:38:51 UTC

[mp1] Still can not get working DSO configuration on Tru64

I've spent two days trying to get working mod_perl compiled as DSO on
Tru64 and still can't succeed. Below I describe what I tried, in case
anyone could suggest something I would be really grateful. I describe
also why such configuration is important for me, in case someone can
suggest alternative solution, I would appreciate it too.

Sideways, I describe minor makefile error which is probably
independent from the whole problem.

*] Background

I have developed some (fairly large) mod_perl application. The
application works perfectly on Tru64 with mod_perl statically linked
with apache (and all other modules as DSO's). It also works perfectly
with fully DSO (with mod_perl.so too) configuration on Debian Gnu
Linux.

I would like to get it working with DSO mod_perl on Tru64 for single
reason: in DSO configuration I can use 'apachectl graceful' to load
the new application version in the matter completely invisible for the
clients (no broken requests, no short period of inavailability). In my
case it would be very demanded feature. At the same time, with
statically linked mod_perl I must use 'apachectl stop; wait a moment;
apachectl start' to load the new version.

It can matter (or not) that my application uses some custom module
implemented in C++ (compiled with Compaq C++ for Tru64) and
referencing 3rd party libraries (interface to some middleware, I'll
not delve into details now but in case you thing they are important
let me know). It could be worth noting that no library mentioned here
links with thread library (so this is not the source of the problem).

*] My attempts

In short: I tried different compilation methods with two possible
outcomes:
a) apache and modperl compile succesfully but I get coredump while the
   application is starting (in all cases SEGVs, in some cases core's
   confused the debugger, in other I managed to notice __at_fork in
   backtrace)
b) everything seem to compile succesfully but I get 
   dlopen: /tools/apache/libexec/mod_perl.so: symbol "PL_perl_destruct_level" unresolved
   while the application is starting

As far as I could checked there were no mistakes like 'using one perl
to compile and the other one to run', I always built everything from
scratch and then tested.

Below I describe different variants of compilation of perl and apache,
I tried most of the 'perl this way, apache that way' combinations.

1) Perl compilation (I use 5.6.1)

I used commands like the one below

   sh Configure -des -Dprefix=/tools/perl -Uinstallusrbinperl \ 
      -Uuseshrplib -Uusemymalloc -Ubincompat5005
   make
   make test
   make install

and also tried all possible combinations of useshrplib and usemymalloc

In all cases perl itself compiled, linked and tested correctly, also
my custom modules compiled and worked)


2) apache (I use 1.3.27) & modperl (I use 1.27)

I tried different combinations described below. 

It is worth noting, that whatever method I choosen there was minor
error if I used -Duseshrplib while building perl: while linking
modperl (libperl.so) I got the following error:

ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.lo perlio.lo mod_perl_opmask.lo Apache.lo Constants.lo ModuleConfig.lo Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.lo -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE  -L/usr/local/lib /tools/perl/lib/5.6.1/alpha-dec_osf/auto/DynaLoader/DynaLoader.a -L/tools/perl/lib/5.6.1/alpha-dec_osf/CORE -lperl -lm -liconv -lutil 
ld:
Invalid flag usage: Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE, -Wx,-o
ption must appear after -_SYSTYPE_SVR4 
ld: Usage: ld [options] file [...]

Simple change in the Makefile - replacing ld with cc - caused this
command to succeed. So in all the cases when I got this error I
patched the problem this way and proceeded.

So here is what I tried

a) Simultaneous compilation

cd mod_perl-1.27
perl Makefile.PL $PERL_MOD_DBG $PLTRACE \ 
      APACHE_SRC=../apache_1.3.27/src \ 
      APACHE_PREFIX=/tools/apache \ 
      USE_APACI=1 \ 
      USE_DSO=1 \ 
      DO_HTTPD=1 \ 
      ALL_HOOKS=1 \ 
      EVERYTHING=1 \ 
      APACI_ARGS="--enable-module=so,\ 
        --prefix=/tools/apache,\ 
        --enable-rule=SHARED_CHAIN,\ 
        --enable-module=access,--enable-shared=access,\ 
        --enable-module=actions,--enable-shared=actions,\ 
        --enable-module=alias,--enable-shared=alias,\ 
        --enable-module=asis,--enable-shared=asis,\ 
        --enable-module=auth,--enable-shared=auth,\ 
        --enable-module=auth_anon,--enable-shared=auth_anon,\ 
        --enable-module=auth_db,--enable-shared=auth_db,\ 
        --enable-module=auth_dbm,--enable-shared=auth_dbm,\ 
        --enable-module=autoindex,--enable-shared=autoindex,\ 
        --enable-module=cern_meta,--enable-shared=cern_meta,\ 
        --enable-module=cgi,--enable-shared=cgi,\ 
        --enable-module=digest,--enable-shared=digest,\ 
        --enable-module=dir,--enable-shared=dir,\ 
        --enable-module=env,--enable-shared=env,\ 
        --enable-module=example,--enable-shared=example,\ 
        --enable-module=expires,--enable-shared=expires,\ 
        --enable-module=headers,--enable-shared=headers,\ 
        --enable-module=imap,--enable-shared=imap,\ 
        --enable-module=include,--enable-shared=include,\ 
        --enable-module=info,--enable-shared=info,\ 
        --enable-module=log_agent,--enable-shared=log_agent,\ 
        --enable-module=log_config,--enable-shared=log_config,\ 
        --enable-module=log_referer,--enable-shared=log_referer,\ 
        --enable-module=mime,--enable-shared=mime,\ 
        --enable-module=mime_magic,--enable-shared=mime_magic,\ 
        --enable-module=mmap_static,--enable-shared=mmap_static,\ 
        --enable-module=negotiation,--enable-shared=negotiation,\ 
        --enable-module=proxy,--enable-shared=proxy,\ 
        --enable-module=rewrite,--enable-shared=rewrite,\ 
        --enable-module=setenvif,--enable-shared=setenvif,\ 
        --enable-module=speling,--enable-shared=speling,\ 
        --enable-module=status,--enable-shared=status,\ 
        --enable-module=unique_id,--enable-shared=unique_id,\ 
        --enable-module=userdir,--enable-shared=userdir,\ 
        --enable-module=usertrack,--enable-shared=usertrack,\ 
        --enable-module=vhost_alias,--enable-shared=vhost_alias,\ 
 " 
make
make install

I also tried without SHARED_CHAIN and with additional
--enable-rule=SHARED_CORE.


b) I also tried apxs variant:

cd apache-1.3.27
./configure --enable-module=so \ 
       --prefix=/tools/apache \ 
       --enable-rule=SHARED_CHAIN \ 
       --enable-module=access --enable-shared=access \ 
       --enable-module=actions --enable-shared=actions \ 
       --enable-module=alias --enable-shared=alias \ 
       --enable-module=asis --enable-shared=asis \ 
       --enable-module=auth --enable-shared=auth \ 
       --enable-module=auth_anon --enable-shared=auth_anon \ 
       --enable-module=auth_db --enable-shared=auth_db \ 
       --enable-module=auth_dbm --enable-shared=auth_dbm \ 
       --enable-module=autoindex --enable-shared=autoindex \ 
       --enable-module=cern_meta --enable-shared=cern_meta \ 
       --enable-module=cgi --enable-shared=cgi \ 
       --enable-module=digest --enable-shared=digest \ 
       --enable-module=dir --enable-shared=dir \ 
       --enable-module=env --enable-shared=env \ 
       --enable-module=example --enable-shared=example \ 
       --enable-module=expires --enable-shared=expires \ 
       --enable-module=headers --enable-shared=headers \ 
       --enable-module=imap --enable-shared=imap \ 
       --enable-module=include --enable-shared=include \ 
       --enable-module=info --enable-shared=info \ 
       --enable-module=log_agent --enable-shared=log_agent \ 
       --enable-module=log_config --enable-shared=log_config \ 
       --enable-module=log_referer --enable-shared=log_referer \ 
       --enable-module=mime --enable-shared=mime \ 
       --enable-module=mime_magic --enable-shared=mime_magic \ 
       --enable-module=mmap_static --enable-shared=mmap_static \ 
       --enable-module=negotiation --enable-shared=negotiation \ 
       --enable-module=proxy --enable-shared=proxy \ 
       --enable-module=rewrite --enable-shared=rewrite \ 
       --enable-module=setenvif --enable-shared=setenvif \ 
       --enable-module=speling --enable-shared=speling \ 
       --enable-module=status --enable-shared=status \ 
       --enable-module=unique_id --enable-shared=unique_id \ 
       --enable-module=userdir --enable-shared=userdir \ 
       --enable-module=usertrack --enable-shared=usertrack \ 
       --enable-module=vhost_alias --enable-shared=vhost_alias
make 
make test 
make install

cd mod_perl-1.27
perl Makefile.PL USE_APXS=1 WITH_APXS=/tools/apache/bin/apxs \ 
   EVERYTHING=1
make 
make install 
 



Is there anything I could try?

Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
Marcin Kasperski <Ma...@acn.waw.pl> writes:

> > The results are exactly the same: link succeeded,
> > PL_perl_destruct_level is unresolved while running apache.
> 
> I found the workaround to avoid this effect: slightly patching apache
> build procedure so that the httpd binary is linked with perl
> libperl.so helped. The error disappears... now I get the coredump
> during the application startup. In case I manage to diagnose this core
> somehow, I will mention it here.

After recompiling perl, apache and modperl with debugging enabled I
got the following backtrace. Does it reminds anything to anyone?  I
suspect something wrong in the fact, that perl_startup is called so
late (during processing some PerlModule...)

(Carp module mentioned there just happened to be the first PerlModule
 mentioned in my apache config)

/apache-1.3.27, modperl-1.27/

Core file produced from executable 'httpd'
Thread terminated at PC 0x3ffbff67de8 by signal SEGV
(ladebug) where
>0  0x3ffbff67de8 in S_new_he() "hv.c":26
#1  0x3ffbff6b194 in Perl_share_hek(str=0x3fffffeed70="@", len=1, hash=66) "hv.c":1484
#2  0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3fffffeed70="@", klen=1, val=0x140048d80, hash=66) "hv.c":413
#3  0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3fffffeed70="@", klen=1, lval=1) "hv.c":210
#4  0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3fffffeed70="@", add=1, sv_type=4) "gv.c":669
#5  0x3ffbfefe56c in S_init_main_stash() "perl.c":2523
#6  0x3ffbfef9c18 in S_parse_body(env=0x0, xsinit=0x3000180ecd8) "perl.c":951
#7  0x3ffbfef9b0c in perl_parse(my_perl=0x140034040, xsinit=0x3000180ecd8, argc=3, argv=0x11fff9c48, env=0x0) "perl.c":895
#8  0x3000180f58c in perl_startup(s=0x14001e860, p=0x14001e818) "mod_perl.c":702
#9  0x30001817070 in perl_cmd_module(parms=0x11fffbe10, dummy=0x14001fdd8, arg=0x140020260="Carp") "perl_config.c":582
#10 0x12001cee8 in invoke_cmd(cmd=0x30041842828, parms=0x11fffbe10, mconfig=0x14001fdd8, args=0x11fff9daf="") "http_config.c":918
#11 0x12001d3ec in ap_handle_command(parms=0x11fffbe10, config=0x14001f250, l=0x11fff9da0="PerlModule Carp") "http_config.c":1030
#12 0x12001d4f8 in ap_srm_command_loop(parms=0x11fffbe10, config=0x14001f250) "http_config.c":1044
#13 0x12001db48 in ap_process_resource_config(s=0x14001e860, fname=0x1400112f0="/home/marcink/GAUSS/igoweb/src/tests/imf_efficiency/apache.conf", p=0x14001e818, ptemp=0x140338818) "http_config.c":1332
#14 0x12001ea30 in ap_read_config(p=0x14001e818, ptemp=0x140338818, confname=0x1400112f0="/home/marcink/GAUSS/igoweb/src/tests/imf_efficiency/apache.conf") "http_config.c":1616
#15 0x120010208 in standalone_main(argc=4, argv=0x11fffc018) "http_main.c":5071
#16 0x120010ce8 in main(argc=4, argv=0x11fffc018) "http_main.c":5456
#17 0x12000aad8 in __start(...) in /home/marcink/tools/apache/bin/httpd

When I removed PerlModule directives and sticked only with
PerlRequire, it occured that I must add 'use Apache;' on the beginning
to use things like Apache->push_handlers (on normal installations it
was not necessary, here I got ). And then I got similar coredump:

Core file produced from executable 'httpd'
Thread terminated at PC 0x3ffbff67de8 by signal SEGV
(ladebug) where
>0  0x3ffbff67de8 in S_new_he() "hv.c":26
#1  0x3ffbff6b194 in Perl_share_hek(str=0x3fffffeed70="@", len=1, hash=66) "hv.c":1484
#2  0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3fffffeed70="@", klen=1, val=0x140048d80, hash=66) "hv.c":413
#3  0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3fffffeed70="@", klen=1, lval=1) "hv.c":210
#4  0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3fffffeed70="@", add=1, sv_type=4) "gv.c":669
#5  0x3ffbfefe56c in S_init_main_stash() "perl.c":2523
#6  0x3ffbfef9c18 in S_parse_body(env=0x0, xsinit=0x3000180ecd8) "perl.c":951
#7  0x3ffbfef9b0c in perl_parse(my_perl=0x140034040, xsinit=0x3000180ecd8, argc=3, argv=0x11fff9c48, env=0x0) "perl.c":895
#8  0x3000180f58c in perl_startup(s=0x14001e860, p=0x14001e818) "mod_perl.c":702
#9  0x30001817274 in perl_cmd_require(parms=0x11fffbe10, dummy=0x14001fdd8, arg=0x140020260="/home/marcink/src/tests/startup.pl") "perl_config.c":613
#10 0x12001cee8 in invoke_cmd(cmd=0x30041842800, parms=0x11fffbe10, mconfig=0x14001fdd8, args=0x11fff9deb="") "http_config.c":918
#11 0x12001d3ec in ap_handle_command(parms=0x11fffbe10, config=0x14001f250, l=0x11fff9da0="PerlRequire /home/marcink/src/tests/startup.pl") "http_config.c":1030
#12 0x12001d4f8 in ap_srm_command_loop(parms=0x11fffbe10, config=0x14001f250) "http_config.c":1044
#13 0x12001db48 in ap_process_resource_config(s=0x14001e860, fname=0x1400112f0="/home/marcink/src/tests/apache.conf", p=0x14001e818, ptemp=0x140235818) "http_config.c":1332
#14 0x12001ea30 in ap_read_config(p=0x14001e818, ptemp=0x140235818, confname=0x1400112f0="/home/marcink/src/tests/efficiency/apache.conf") "http_config.c":1616
#15 0x120010208 in standalone_main(argc=4, argv=0x11fffc018) "http_main.c":5071
#16 0x120010ce8 in main(argc=4, argv=0x11fffc018) "http_main.c":5456
#17 0x12000aad8 in __start(...) in /home/marcink/tools/apache/bin/httpd

Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
> The results are exactly the same: link succeeded,
> PL_perl_destruct_level is unresolved while running apache.

I found the workaround to avoid this effect: slightly patching apache
build procedure so that the httpd binary is linked with perl
libperl.so helped. The error disappears... now I get the coredump
during the application startup. In case I manage to diagnose this core
somehow, I will mention it here.


-- 
( Marcin Kasperski   | A complex system designed from scratch never works    )
( http://www.mk.w.pl |    and cannot be patched to make it work. (Booch)     )
(----------------------------------------------------------------------------)
( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle     )

Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
> The problem is that the 
>         -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE
> option (which, by the way, is returned by
>         perl -V:ccdlflags
> when perl is compiled with -Duseshrplib) is not an option for 'ld' but
> for 'cc'. In fact it means 'dear cc, be so kind and pass to ld 
> the option -rpath /tools/perl/lib/5.6.1/alpha-dec_osf/CORE). ld does
> not know '-Wl' and complains. As 
>         perl -V:ld
> returns 'ld', maybe this is the problem in perl, not in modperl, but I
> am not sure.
> 
> I patched it just by replacing 'ld' with 'cc' in the Makefile
> generated by configure script - such correction caused link step to
> succeed (and 'unresolved PL_perl_destruct_level to be reported while
> apache startup' :-( )
> 
> Currently I plan to check the opposite correction (using -rpath
> .. and ld as link command), maybe this will change something.

I tried it - I left ld as link command but replaced in Makefile
   -Wl,-rpath,/tools/...  
with 
   -rpath /tools/...
The results are exactly the same: link succeeded,
PL_perl_destruct_level is unresolved while running apache.

-- 
( Marcin Kasperski   | Communication takes place between people, documents   )
( http://www.mk.w.pl |                are secondary. (Booch)                 )
(----------------------------------------------------------------------------)
( Sztuczki i kruczki w C++: http://www.mk.w.pl/porady/porady_cplusplus       )

Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
Stas Bekman <st...@stason.org> writes:

> >>Marcin Kasperski wrote:
> [...]
> > It seems to me, they had problem with the '-Wl,-rpath' issue which I
> > found to be minor and easily patched (by the way: maybe someone would
> > want to correct it in distribution?).
> 
> I wasn't following that thread, but if you send a patch that solves
> that problem, I'd be more than happy to commit it to the main distro.

Hmm, so far I can only offer 'half-patch' and the problem explanation
(I do not understand configure scripts well enough to guess how to
correct them).

The problem is that the 
        -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE
option (which, by the way, is returned by
        perl -V:ccdlflags
when perl is compiled with -Duseshrplib) is not an option for 'ld' but
for 'cc'. In fact it means 'dear cc, be so kind and pass to ld 
the option -rpath /tools/perl/lib/5.6.1/alpha-dec_osf/CORE). ld does
not know '-Wl' and complains. As 
        perl -V:ld
returns 'ld', maybe this is the problem in perl, not in modperl, but I
am not sure.

I patched it just by replacing 'ld' with 'cc' in the Makefile
generated by configure script - such correction caused link step to
succeed (and 'unresolved PL_perl_destruct_level to be reported while
apache startup' :-( )

Currently I plan to check the opposite correction (using -rpath
... and ld as link command), maybe this will change something.

-- 
( Marcin Kasperski   | Working overtime sucks the spirit and motivation      )
( http://www.mk.w.pl |               out of a team. (Wells)                  )
(----------------------------------------------------------------------------)
( Porady dla twórców serwisów WWW: http://www.mk.w.pl/porady/porady_www      )

Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
Stas Bekman <st...@stason.org> writes:

> Marcin Kasperski wrote:
> >>In short: I tried different compilation methods with two possible
> >>outcomes:
> >>a) apache and modperl compile succesfully but I get coredump while the
> >>   application is starting (in all cases SEGVs, in some cases core's
> >>   confused the debugger, in other I managed to notice __at_fork in
> >>   backtrace)
> >> b) everything seem to compile succesfully but I get dlopen:
> >>    /tools/apache/libexec/mod_perl.so: symbol
> >>    "PL_perl_destruct_level" unresolved
> 
> >>   while the application is starting
> > Maybe it is worth noting, that I happened to get b) also when I
> 
> > compiled perl with shared perl library (in contrary to suggestion
> > found in modperl docs that building perl with shared library should
> > help).
> 
> 2 years ago, there was a similar struggle as you can see from this
> thread: http://marc.theaimsgroup.com/?t=97442230600001&r=1&w=2 May
> be those participants are still using True64 and can give you some
> hints?

It seems to me, they had problem with the '-Wl,-rpath' issue which I
found to be minor and easily patched (by the way: maybe someone would
want to correct it in distribution?). And all they wanted was to get
statically linked modperl. This is the thing I already have.

Maybe I will post a question to tru64-managers...




-- 
( Marcin Kasperski   | (...) the only completion criterion for the Analysis  )
( http://www.mk.w.pl |       and Design phases is - the date. (Martin)       )
(----------------------------------------------------------------------------)
( Nie gub zgłoszeń błędów: http://www.mk.w.pl/narzedzia/narzedzia_bugewid    )

Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Stas Bekman <st...@stason.org>.
Marcin Kasperski wrote:
>>In short: I tried different compilation methods with two possible
>>outcomes:
>>a) apache and modperl compile succesfully but I get coredump while the
>>   application is starting (in all cases SEGVs, in some cases core's
>>   confused the debugger, in other I managed to notice __at_fork in
>>   backtrace)
>>b) everything seem to compile succesfully but I get 
>>   dlopen: /tools/apache/libexec/mod_perl.so: symbol "PL_perl_destruct_level" unresolved
>>   while the application is starting
> 
> 
> Maybe it is worth noting, that I happened to get b) also when I
> compiled perl with shared perl library (in contrary to suggestion
> found in modperl docs that building perl with shared library should
> help).

2 years ago, there was a similar struggle as you can see from this thread:
http://marc.theaimsgroup.com/?t=97442230600001&r=1&w=2
May be those participants are still using True64 and can give you some 
hints?

__________________________________________________________________
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


Re: [mp1] Still can not get working DSO configuration on Tru64

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
> In short: I tried different compilation methods with two possible
> outcomes:
> a) apache and modperl compile succesfully but I get coredump while the
>    application is starting (in all cases SEGVs, in some cases core's
>    confused the debugger, in other I managed to notice __at_fork in
>    backtrace)
> b) everything seem to compile succesfully but I get 
>    dlopen: /tools/apache/libexec/mod_perl.so: symbol "PL_perl_destruct_level" unresolved
>    while the application is starting

Maybe it is worth noting, that I happened to get b) also when I
compiled perl with shared perl library (in contrary to suggestion
found in modperl docs that building perl with shared library should
help).

Re: [mp1] Partial success working on Tru64/DSO

Posted by Marcin Kasperski <Ma...@acn.waw.pl>.
> (... revisiting old thread about my problems with compiling 
> apache/mod_perl as DSO on Tru64 unix)

My problem is still not solved but I get it up to the point where it
probably lies in some customary modules (which does not behave
correctly when unloaded/reloaded) and is not directly related to
apache/mod_perl.

As I got the minimal success (some simple mod_perl application
worked), I report here the way I compiled perl/apache/mod_perl in
that case. Maybe it will help someone in similar situation.

Below I cite the main parts of the script I used (with unnecessary
details omitted):



WORK_DIR=$HOME/tools_src
DIST_DIR=$HOME/DOWNLOAD
INST_DIR=$HOME/tools

PERL_INST_DIR=$INST_DIR/perl
APACHE_INST_DIR=$INST_DIR/apache

############################################################

PERL_VERSION=perl-5.6.1
APACHE_VERSION=apache_1.3.27
MOD_PERL_VERSION=mod_perl-1.27
LIBAPREQ_VERSION=libapreq-1.0
DIGEST_MD5_VERSION=Digest-MD5-2.20
MIME_BASE64_VERSION=MIME-Base64-2.12
# ... cut a lot of other modules which are out-of-topic here

#################################################################

unpack() {
  if [ -d $1 ]; then
     rm -rf $1
  fi
  echo -n "Unpacking $1..."
  gunzip -c $DIST_DIR/$1.tar.gz | tar xf -
  echo "done"
}

#################################################################

if [ ! -d $WORK_DIR ]; then
    mkdir -p $WORK_DIR
fi

if [ ! -d $INST_DIR ]; then
    mkdir -p $INST_DIR
fi

#################################################################

cd $WORK_DIR
unpack $PERL_VERSION
cd $PERL_VERSION
  # Some commments:
  # -Uinstallusrbinperl in my case I use customary install directory
  # -Uuseshrplib there is a makefile problem and compilation error
  #  when we define it (which we try to patch below, so please 
  #  experiment if you like)
  # -Uusemymalloc on 64bit platforms it is recommended according to some docs
  # -Ubincompat5005 we don't want coredumps caused by name conflicts
  #  of malloc/free
  # -Dusemultiplicity it helps a bit with DSO reloading
sh Configure -des -Dprefix=$PERL_INST_DIR -Uinstallusrbinperl \
      -Uuseshrplib -Uusemymalloc -Ubincompat5005 \
      -Dusemultiplicity
make
make test
make install


#---- don't forget it when installing outside defaults 
PATH=$PERL_INST_DIR/bin:$PATH; export PATH

#################################################################

build_module() {
  MOD=$1
  cd $WORK_DIR
  unpack $MOD
  cd $WORK_DIR/$MOD
  perl Makefile.PL $2 $3 $4 $5 $6 $7 $8 $9
  make
  make test
  make install
}

build_module $DIGEST_MD5_VERSION
build_module $MIME_BASE64_VERSION
# ... cut others ...

#################################################################

unpack $APACHE_VERSION
unpack $MOD_PERL_VERSION

cd $WORK_DIR/$MOD_PERL_VERSION

perl Makefile.PL $PERL_MOD_DBG $PLTRACE \
     APACHE_SRC=../$APACHE_VERSION/src \
     APACHE_PREFIX=$APACHE_INST_DIR \
     USE_APACI=1 \
     USE_DSO=1 \
     DO_HTTPD=1 \
     ALL_HOOKS=1 \
     EVERYTHING=1 \
     APACI_ARGS="--enable-module=so,\
        --prefix=$APACHE_INST_DIR,\
        --enable-module=access,--enable-shared=access,\
        --enable-module=actions,--enable-shared=actions,\
        --enable-module=alias,--enable-shared=alias,\
        --enable-module=asis,--enable-shared=asis,\
        --enable-module=auth,--enable-shared=auth,\
        --enable-module=auth_anon,--enable-shared=auth_anon,\
        --enable-module=auth_db,--enable-shared=auth_db,\
        --enable-module=auth_dbm,--enable-shared=auth_dbm,\
        --enable-module=autoindex,--enable-shared=autoindex,\
        --enable-module=cern_meta,--enable-shared=cern_meta,\
        --enable-module=cgi,--enable-shared=cgi,\
        --enable-module=digest,--enable-shared=digest,\
        --enable-module=dir,--enable-shared=dir,\
        --enable-module=env,--enable-shared=env,\
        --enable-module=example,--enable-shared=example,\
        --enable-module=expires,--enable-shared=expires,\
        --enable-module=headers,--enable-shared=headers,\
        --enable-module=imap,--enable-shared=imap,\
        --enable-module=include,--enable-shared=include,\
        --enable-module=info,--enable-shared=info,\
        --enable-module=log_agent,--enable-shared=log_agent,\
        --enable-module=log_config,--enable-shared=log_config,\
        --enable-module=log_referer,--enable-shared=log_referer,\
        --enable-module=mime,--enable-shared=mime,\
        --enable-module=mime_magic,--enable-shared=mime_magic,\
        --enable-module=mmap_static,--enable-shared=mmap_static,\
        --enable-module=negotiation,--enable-shared=negotiation,\
        --enable-module=proxy,--enable-shared=proxy,\
        --enable-module=rewrite,--enable-shared=rewrite,\
        --enable-module=setenvif,--enable-shared=setenvif,\
        --enable-module=speling,--enable-shared=speling,\
        --enable-module=status,--enable-shared=status,\
        --enable-module=unique_id,--enable-shared=unique_id,\
        --enable-module=userdir,--enable-shared=userdir,\
        --enable-module=usertrack,--enable-shared=usertrack,\
        --enable-module=vhost_alias,--enable-shared=vhost_alias,\
"

# Correcting the makefile error resulting in compilation error when
# perl is compiled with shared library
perl -i.orig -pe 's/-Wl,-rpath,/-rpath /' \
    ../$APACHE_VERSION/src/modules/perl/Makefile

make
make test 
make install



# libperl.so name for mod_perl is plain stupid, let's follow the Debian way
echo -n "Renaming libperl.so to mod_perl.so, use this name in httpd.conf"
mv $APACHE_INST_DIR/libexec/libperl.so $APACHE_INST_DIR/libexec/mod_perl.so
echo "Done"

#######################################################################

# Modules dependent from modperl....

cd $WORK_DIR
build_module $LIBAPREQ_VERSION