Re: [mp1] Still can not get working DSO configuration on Tru64
Stas Bekman [EMAIL PROTECTED] 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 twrcw serwisw WWW: http://www.mk.w.pl/porady/porady_www )
Re: [mp1] Still can not get working DSO configuration on Tru64
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
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
Marcin Kasperski [EMAIL PROTECTED] 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=0x3feed70=@, len=1, hash=66) hv.c:1484 #2 0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3feed70=@, klen=1, val=0x140048d80, hash=66) hv.c:413 #3 0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3feed70=@, klen=1, lval=1) hv.c:210 #4 0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3feed70=@, 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=0x3feed70=@, len=1, hash=66) hv.c:1484 #2 0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3feed70=@, klen=1, val=0x140048d80, hash=66) hv.c:413 #3 0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3feed70=@, klen=1, lval=1) hv.c:210 #4 0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3feed70=@, 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
Stas Bekman [EMAIL PROTECTED] 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=9744223061r=1w=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 zgosze bdw: http://www.mk.w.pl/narzedzia/narzedzia_bugewid)
Re: [mp1] Still can not get working DSO configuration on Tru64
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] Still can not get working DSO configuration on Tru64
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=9744223061r=1w=2 May be those participants are still using True64 and can give you some hints? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
