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
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
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
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
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
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
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
