You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/06/30 07:03:10 UTC
[mp2] recent 5.6.x breakage
It seems that perl 5.6.x is no longer working with mp2, and that's a pretty
recent breakage I believe.
The server fails to start:
Cannot load
/home/stas/apache.org/mp2-pool/src/modules/perl/mod_perl.so into
server: /home/stas/apache.org/mp2-pool/src/modules/perl/mod_perl.so:
undefined symbol: boot_DynaLoader
This happens because
my $ldopts = ExtUtils::Embed::ldopts();
from Apache::Build doesn't get Dynaloader.a included. This in turn happens
because something happens to catdir. In ExtUtils::Embed::ldopts, the line
$root = $MM->catdir(@ns);
passes "DynaLoader" as the only contents of @ns, but catdir receives
some bogus object parameter: MY=HASH(0x9379394)
Here is the output from debuger:
DB<4> n
ExtUtils::Embed::ldopts(/home/stas/perl/5.6.1/lib/5.6.1/ExtUtils/Embed.pm:188):
188: $root = $MM->catdir(@ns);
DB<4> p $sub
DynaLoader
DB<5> p @ns
DynaLoader
DB<6> s
File::Spec::Functions::CODE(0x81e9664)(/home/stas/perl/5.6.1/lib/5.6.1/File/Spec/Functions.pm:41):
41: *{$meth} = sub {&$sub('File::Spec', @_)};
DB<6> p "@_"
MY=HASH(0x9379394) DynaLoader
Someone messes with catdir, but I can't figure out where does this
happen.
Randy, is it possible that some recent win32 changes have caused that?
I see that problem on linux, but is it possible that some catdir
override has happened?
The standalone ldopts works just fine:
% perl-5.6.1 -MExtUtils::Embed -e ldopts
-rdynamic -Wl,-rpath,/home/stas/perl/5.6.1/lib/5.6.1/i686-linux-perlio/CORE
-L/usr/local/lib
/home/stas/perl/5.6.1/lib/5.6.1/i686-linux-perlio/auto/DynaLoader/DynaLoader.a
-L/home/stas/perl/5.6.1/lib/5.6.1/i686-linux-perlio/CORE -lperl -lnsl -ldl -lm
-lc -lcrypt -lutil
so something happens during 'perl Makefile.PL' that breaks catdir I
believe.
It's strange that it happens only to 5.6.x versions of perl.
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 30 Jun 2004, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Doing binary search on various checkout dates, it showed
>>>that the guilty change is:
>
>
> Nice work, Stas! Sorry for causing you the extra work -
> I'm sure you didn't need it ...
Ah, no worries Randy, you couldn't have known about this MakeMaker <fill in
here the right word>. Your code was perfectly correct.
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 30 Jun 2004, Stas Bekman wrote:
> Stas Bekman wrote:
> > Doing binary search on various checkout dates, it showed
> > that the guilty change is:
Nice work, Stas! Sorry for causing you the extra work -
I'm sure you didn't need it ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] recent 5.6.x breakage
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Doing binary search on various checkout dates, it showed that the guilty
> change is:
And the fix (workaround) is:
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.140
diff -u -r1.140 Makefile.PL
--- Makefile.PL 27 Jun 2004 23:41:06 -0000 1.140
+++ Makefile.PL 30 Jun 2004 22:53:03 -0000
@@ -472,7 +472,6 @@
package MY;
use Config;
-use File::Spec::Functions qw(catdir);
use constant WIN32 => $^O eq 'MSWin32';
my $apache_test_install;
@@ -489,7 +488,7 @@
if (WIN32) {
ModPerl::MM::add_dep(\$string, pure_all => 'aprext');
- my $aprext = catdir qw(xs APR aprext);
+ my $aprext = File::Spec->catdir(qw(xs APR aprext));
$string .= <<"EOF";
aprext:
Apparently MakeMaker in 5.6.x was a bit broken...
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Stas Bekman <st...@stason.org>.
Doing binary search on various checkout dates, it showed that the guilty
change is:
diff -ru --exclude=CVS mp2-20040620/Makefile.PL mp2-20040621/Makefile.PL
--- mp2-20040620/Makefile.PL 2004-03-03 19:36:18.000000000 -0800
+++ mp2-20040621/Makefile.PL 2004-06-20 23:45:54.000000000 -0700
@@ -153,11 +153,19 @@
#Makefile.PL's in WrapXS/ just need to pass the -e mod_perl.lib test
#the real mod_perl.lib will be in place when WrapXS/ dll's are
#actually linked
- my $lib = "src/modules/perl/$build->{MP_LIBNAME}.lib";
- unless (-e $lib) {
- open my $fh, '>', $lib or die "open $lib: $!";
- print $fh "#this is a dummy file to trick MakeMaker";
- close $fh;
+ require File::Path;
+ my $lib1 = "src/modules/perl/$build->{MP_LIBNAME}.lib";
+ my $apr_blib = catdir qw(blib arch Apache2 auto APR);
+ unless (-d $apr_blib) {
+ File::Path::mkpath($apr_blib) or die "mkdir $apr_blib failed: $!";
+ }
+ my $lib2 = catfile $apr_blib, 'APR.lib';
+ foreach my $lib ($lib1, $lib2) {
+ unless (-e $lib) {
+ open my $fh, '>', $lib or die "open $lib: $!";
+ print $fh "#this is a dummy file to trick MakeMaker";
+ close $fh;
+ }
}
}
@@ -448,6 +456,8 @@
package MY;
use Config;
+use File::Spec::Functions qw(catdir);
+use constant WIN32 => $^O eq 'MSWin32';
my $apache_test_install;
BEGIN {
@@ -460,6 +470,18 @@
my $self = shift;
my $string = $self->ModPerl::BuildMM::MY::top_targets;
+ if (WIN32) {
+ ModPerl::MM::add_dep(\$string, pure_all => 'apr_lib');
+
+ my $apr_lib = catdir qw(xs APR APR);
+ $string .= <<"EOF";
+
+apr_lib:
+ cd "$apr_lib" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
+
+EOF
+ }
+
ModPerl::MM::add_dep(\$string, pure_all => 'modperl_lib');
$string .= <<'EOF';
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 30 Jun 2004, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>
> [ .. ]
>
>>>I think the difference is is that I installed
>>>ExtUtils::Embed from the perl-5.8.4 distribution, and it's
>>>marked as version 1.2506_01, which being a development
>>>version, doesn't show up on CPAN.pm.
>>
>>It's not about us, but users who won't have that version in any case.
>
>
> That's true - I was just wondering if it was a problem
> (that's been fixed) with the older ExtUtils::Embed, or
> something else.
Nuh, it's something we have done in the last month that broke it.
>>>>Though I can't quite figure out how that objects becomes
>>>>an argument to catdir.
>>>
>>>
>>>Another thing that occurred to me - with the recent
>>>APR/mod_perl.so decoupling, a warning comes up at the 'perl
>>>Makefile.PL' stage concerning MY::postamble being redefined
>>>from xs/APR/APR/Makefile.PL and xs/APR/aprext/Makefile.PL.
>>>Might this be at all related?
>>
>>Yes, I've mentioned that issue when I posted my original
>>patch. I've spent some time trying to get rid of it, but
>>in vain. I'll try again today. It might be releated.
>
>
> Although this doesn't solve the basic problem of getting rid
> of the warnings in general, does the following help? It just
> copies the relevant files via File::Copy, rather than doing
> so via Makefile - it would at least show if the problem
> arises because of the MY::postamble redefinitions.
It doesn't help :(
As for getting rid of the warning I'm not sure whether it's the best to copy
the files from Makefile.PL -- it might be too early for autogenerated files
(which might be added later) as some get generated later on.
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 30 Jun 2004, Stas Bekman wrote:
> Randy Kobes wrote:
[ .. ]
> > I think the difference is is that I installed
> > ExtUtils::Embed from the perl-5.8.4 distribution, and it's
> > marked as version 1.2506_01, which being a development
> > version, doesn't show up on CPAN.pm.
>
> It's not about us, but users who won't have that version in any case.
That's true - I was just wondering if it was a problem
(that's been fixed) with the older ExtUtils::Embed, or
something else.
> >>Though I can't quite figure out how that objects becomes
> >>an argument to catdir.
> >
> >
> > Another thing that occurred to me - with the recent
> > APR/mod_perl.so decoupling, a warning comes up at the 'perl
> > Makefile.PL' stage concerning MY::postamble being redefined
> > from xs/APR/APR/Makefile.PL and xs/APR/aprext/Makefile.PL.
> > Might this be at all related?
>
> Yes, I've mentioned that issue when I posted my original
> patch. I've spent some time trying to get rid of it, but
> in vain. I'll try again today. It might be releated.
Although this doesn't solve the basic problem of getting rid
of the warnings in general, does the following help? It just
copies the relevant files via File::Copy, rather than doing
so via Makefile - it would at least show if the problem
arises because of the MY::postamble redefinitions.
==========================================================
Index: xs/APR/APR/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/Makefile.PL,v
retrieving revision 1.23
diff -u -r1.23 Makefile.PL
--- xs/APR/APR/Makefile.PL 28 Jun 2004 02:10:02 -0000 1.23
+++ xs/APR/APR/Makefile.PL 30 Jun 2004 18:17:46 -0000
@@ -7,6 +7,7 @@
use Apache::Build ();
use Config;
use File::Spec::Functions;
+use File::Copy;
use constant WIN32 => Apache::Build::WIN32;
use constant SOLARIS => $^O eq 'solaris';
@@ -72,19 +73,11 @@
push @clean, $cfile;
$src{$cfile} = "$srcdir/$cfile";
}
+for (keys %src) {
+ copy($src{$_}, '.') or die "Cannot copy $_: $!";
+}
$args{OBJECT} = WIN32 ? "APR.o" : "APR.o @obj";
$args{clean} = { FILES => "@clean" };
ModPerl::BuildMM::WriteMakefile(%args);
-
-sub MY::postamble {
- my $self = shift;
- my $string = $self->ModPerl::BuildMM::MY::postamble;
-
- $string .= join '', map {
- "$_: $src{$_}\n\t\$(CP) $src{$_} .\n";
- } keys %src;
-
- return $string;
-}
Index: xs/APR/aprext/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/aprext/Makefile.PL,v
retrieving revision 1.2
diff -u -r1.2 Makefile.PL
--- xs/APR/aprext/Makefile.PL 28 Jun 2004 02:10:02 -0000 1.2
+++ xs/APR/aprext/Makefile.PL 30 Jun 2004 18:17:46 -0000
@@ -16,6 +16,12 @@
push @clean, $cfile;
$src{$cfile} = "$srcdir/$cfile";
}
+if(Apache::Build::WIN32) {
+ require File::Copy;
+ for (keys %src) {
+ File::Copy::copy($src{$_}, '.') or die "Cannot copy $_: $!";
+ }
+}
my @skip = qw(dynamic test);
push @skip, q{static} unless Apache::Build::WIN32;
@@ -29,13 +35,3 @@
);
ModPerl::BuildMM::WriteMakefile(%args);
-
-sub MY::postamble {
- my $self = shift;
- my $string = $self->ModPerl::BuildMM::MY::postamble;
-
- $string .= join '', map {
- "$_: $src{$_}\n\t\$(CP) $src{$_} .\n";
- } keys %src;
- return $string;
-}
============================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] recent 5.6.x breakage
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 29 Jun 2004, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>
> [ ... ]
>
>>>I looked at my ExtUtils::Embed. One, version 1.2505, has
>>> $root = $MM->catdir(@ns);
>>>where
>>> my $MM = bless {} => 'MY';
>>>from a few lines earlier. Perhaps the stray MY object
>>>reference is related to this "MY". Can you see what
>>>happens if you upgrade ExtUtils::Embed - version
>>>1.25061 has the corresponding line
>>> $root = File::Spec->catdir(@ns);
>>
>>CPAN has only 1.2505 or at least that's what it shows:
>>
>>Going to read /home/stas/.cpan/sources/modules/03modlist.data.gz
>>Module id = ExtUtils::Embed
>> DESCRIPTION Utilities for embedding Perl in C/C++ apps
>> CPAN_USERID DOUGM (Doug MacEachern <do...@pobox.com>)
>> CPAN_VERSION 1.2505
>> CPAN_FILE D/DO/DOUGM/ExtUtils-Embed-1.14.tar.gz
>> DSLI_STATUS Sdpf (standard,developer,perl,functions)
>> MANPAGE ExtUtils::Embed - Utilities for embedding Perl in C/C++
>>applications
>> INST_FILE /home/stas/perl/5.6.1/lib/5.6.1/ExtUtils/Embed.pm
>> INST_VERSION 1.2505
>
>
> I think the difference is is that I installed
> ExtUtils::Embed from the perl-5.8.4 distribution, and it's
> marked as version 1.2506_01, which being a development
> version, doesn't show up on CPAN.pm.
It's not about us, but users who won't have that version in any case.
>>Though I can't quite figure out how that objects becomes
>>an argument to catdir.
>
>
> Another thing that occurred to me - with the recent
> APR/mod_perl.so decoupling, a warning comes up at the 'perl
> Makefile.PL' stage concerning MY::postamble being redefined
> from xs/APR/APR/Makefile.PL and xs/APR/aprext/Makefile.PL.
> Might this be at all related?
Yes, I've mentioned that issue when I posted my original patch. I've spent
some time trying to get rid of it, but in vain. I'll try again today. It might
be releated.
> I've noticed that File-Spec hasn't changed on CPAN
> since December last year, but Cwd has changed recently.
Yup, but it's a problem on our side I believe. All those MY:: overrides.
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 29 Jun 2004, Stas Bekman wrote:
> Randy Kobes wrote:
[ ... ]
> > I looked at my ExtUtils::Embed. One, version 1.2505, has
> > $root = $MM->catdir(@ns);
> > where
> > my $MM = bless {} => 'MY';
> > from a few lines earlier. Perhaps the stray MY object
> > reference is related to this "MY". Can you see what
> > happens if you upgrade ExtUtils::Embed - version
> > 1.25061 has the corresponding line
> > $root = File::Spec->catdir(@ns);
>
> CPAN has only 1.2505 or at least that's what it shows:
>
> Going to read /home/stas/.cpan/sources/modules/03modlist.data.gz
> Module id = ExtUtils::Embed
> DESCRIPTION Utilities for embedding Perl in C/C++ apps
> CPAN_USERID DOUGM (Doug MacEachern <do...@pobox.com>)
> CPAN_VERSION 1.2505
> CPAN_FILE D/DO/DOUGM/ExtUtils-Embed-1.14.tar.gz
> DSLI_STATUS Sdpf (standard,developer,perl,functions)
> MANPAGE ExtUtils::Embed - Utilities for embedding Perl in C/C++
> applications
> INST_FILE /home/stas/perl/5.6.1/lib/5.6.1/ExtUtils/Embed.pm
> INST_VERSION 1.2505
I think the difference is is that I installed
ExtUtils::Embed from the perl-5.8.4 distribution, and it's
marked as version 1.2506_01, which being a development
version, doesn't show up on CPAN.pm.
> Though I can't quite figure out how that objects becomes
> an argument to catdir.
Another thing that occurred to me - with the recent
APR/mod_perl.so decoupling, a warning comes up at the 'perl
Makefile.PL' stage concerning MY::postamble being redefined
from xs/APR/APR/Makefile.PL and xs/APR/aprext/Makefile.PL.
Might this be at all related?
I've noticed that File-Spec hasn't changed on CPAN
since December last year, but Cwd has changed recently.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dropping 5.6.x support
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Nope, I haven't run smoke against 5.6.x for quite some time. I think
>>since 1.99_14 was released.
>
>
> I think it is time we re-evaluated support for 5.6.x.
>
> I would suggest we drop support for the 5.6 branch entirely. here is why:
>
> - we spend lots of time on threads and require 5.8.x thread foo. saying
> "5.6.x for prefork and 5.8.x for threads" is really just setting us up for
> lots of problem reports for when people fiddle with the mpm post
> compilation. everyone knows it is possible to compile with both mpms and
> choose after the fact, right?
I'm not sure what you mean here.
> - our resources are limited. with just the handful of us being active it
> is practically impossible to keep up with all the generations of httpd and
> perl. supporting just the 5.8.x tree alone is about to give us _5_
> different versions of perl to accommodate internally with the impending
> release of 5.8.5.
we don't spend any time supporting 5.6.x at the moment. All the initial issues
were figured out long time ago. This recent breakage is our problem, we just
need to figure out what we did. The MakeMaker craft makes it hard to figure out.
> - we are still not at 2.0 yet, so now is the time to drop support for
> older versions, not after we move to 2.0 and find it is just a pain to
> support 5.6.x.
>
> personally, I am just fine with leaving 5.6.x behind. who among us even
> runs 5.6? by this I mean that, as developers, it is impractical to say we
> support a perl version that none of us even tests against on a semi-regular
> basis, especially one that is as old (both in age and in version) as 5.6.1
> is. we are but a few, and we do our best to make everyone happy, but the
> reality is that we can't handle everything, and I would rather see resources
> go toward cool things like separating APR and integrating new httpd 2.2
> features when it arrives over supporting older httpd or perl versions.
I really can't see why have you decided to suggest that? We haven't had 5.6.x
issues in a long long time, and we will nail that one and move on.
We just need to run builds on all configurations more often, so it's easier to
figure out what change broke things. And than the overhead of fixing it is small.
If we get to a situation where we start constantly spend time writing
workarounds for 5.6.x, then yes, we could have done that.
The main objection to dropping 5.6.x support, is that by dropping it you risk
losing users, especially new ones, who may have given mp2 a try, but the
initial cost of upgrading to 5.8.x might be a turn-off.
--
__________________________________________________________________
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
dropping 5.6.x support (was: [mp2] recent 5.6.x breakage)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Nope, I haven't run smoke against 5.6.x for quite some time. I think
> since 1.99_14 was released.
I think it is time we re-evaluated support for 5.6.x.
I would suggest we drop support for the 5.6 branch entirely. here is why:
- we spend lots of time on threads and require 5.8.x thread foo. saying
"5.6.x for prefork and 5.8.x for threads" is really just setting us up for
lots of problem reports for when people fiddle with the mpm post
compilation. everyone knows it is possible to compile with both mpms and
choose after the fact, right?
- our resources are limited. with just the handful of us being active it
is practically impossible to keep up with all the generations of httpd and
perl. supporting just the 5.8.x tree alone is about to give us _5_
different versions of perl to accommodate internally with the impending
release of 5.8.5.
- we are still not at 2.0 yet, so now is the time to drop support for
older versions, not after we move to 2.0 and find it is just a pain to
support 5.6.x.
personally, I am just fine with leaving 5.6.x behind. who among us even
runs 5.6? by this I mean that, as developers, it is impractical to say we
support a perl version that none of us even tests against on a semi-regular
basis, especially one that is as old (both in age and in version) as 5.6.1
is. we are but a few, and we do our best to make everyone happy, but the
reality is that we can't handle everything, and I would rather see resources
go toward cool things like separating APR and integrating new httpd 2.2
features when it arrives over supporting older httpd or perl versions.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] recent 5.6.x breakage
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 29 Jun 2004, Stas Bekman wrote:
>
>
>>It seems that perl 5.6.x is no longer working with mp2, and that's a pretty
>>recent breakage I believe.
>>
>>The server fails to start:
>>
>>Cannot load
>>/home/stas/apache.org/mp2-pool/src/modules/perl/mod_perl.so into
>>server: /home/stas/apache.org/mp2-pool/src/modules/perl/mod_perl.so:
>>undefined symbol: boot_DynaLoader
>>
>>This happens because
>>
>> my $ldopts = ExtUtils::Embed::ldopts();
>>
>>from Apache::Build doesn't get Dynaloader.a included. This in turn happens
>>because something happens to catdir. In ExtUtils::Embed::ldopts, the line
>>
>> $root = $MM->catdir(@ns);
>>
>>passes "DynaLoader" as the only contents of @ns, but catdir receives
>>some bogus object parameter: MY=HASH(0x9379394)
>>
>>Here is the output from debuger:
>>
>> DB<4> n
>>ExtUtils::Embed::ldopts(/home/stas/perl/5.6.1/lib/5.6.1/ExtUtils/Embed.pm:188):
>>188: $root = $MM->catdir(@ns);
>>
>> DB<4> p $sub
>>DynaLoader
>>
>> DB<5> p @ns
>>DynaLoader
>>
>> DB<6> s
>>File::Spec::Functions::CODE(0x81e9664)(/home/stas/perl/5.6.1/lib/5.6.1/File/Spec/Functions.pm:41):
>>41: *{$meth} = sub {&$sub('File::Spec', @_)};
>>
>> DB<6> p "@_"
>>MY=HASH(0x9379394) DynaLoader
>>
>>Someone messes with catdir, but I can't figure out where does this
>>happen.
>>
>>Randy, is it possible that some recent win32 changes have caused that?
>>I see that problem on linux, but is it possible that some catdir
>>override has happened?
>
>
> Hi Stas,
>
> Although anything's possible, of course, I don't see at the
> moment where this happened due to recent win32 changes. The
> changes concerning decoupling APR from mod_perl specific to
> Win32 were all wrapped around if(WIN32) {}, except for
> building xs/APR/aprext/, which should do nothing on
> non-Win32, as the dynamic and static targets were skipped.
> Before this sequence of changes there were some Win32 ones
> in the tests, but these probably are irrelevant to this
> problem.
It's quite possible. Next I'll try to checkout snapshots at various dates over
the last few months and see when it got broken. Ideally we should run the
smoke against all perls more often, but my notebook is already more useful for
cooking eggs than coding, so I do it only once in a while and then when things
go broken, one needs to figure it out the hard way.
I think it may be the order of things in Makefile.PL that have caused this
breakage. I'll work more on this tomorrow.
> Unfortunately, I don't have a perl-5.6 available (except
> for a Win32 one, but that can't build mp2). Do you know if
> it was working before I committed your large patch for
> decoupling APR from mod_perl.so (before any of the Win32
> stuff was put in)?
Nope, I haven't run smoke against 5.6.x for quite some time. I think since
1.99_14 was released.
> I looked at my ExtUtils::Embed. One, version 1.2505, has
> $root = $MM->catdir(@ns);
> where
> my $MM = bless {} => 'MY';
> from a few lines earlier. Perhaps the stray MY object
> reference is related to this "MY". Can you see what
> happens if you upgrade ExtUtils::Embed - version
> 1.25061 has the corresponding line
> $root = File::Spec->catdir(@ns);
CPAN has only 1.2505 or at least that's what it shows:
Going to read /home/stas/.cpan/sources/modules/03modlist.data.gz
Module id = ExtUtils::Embed
DESCRIPTION Utilities for embedding Perl in C/C++ apps
CPAN_USERID DOUGM (Doug MacEachern <do...@pobox.com>)
CPAN_VERSION 1.2505
CPAN_FILE D/DO/DOUGM/ExtUtils-Embed-1.14.tar.gz
DSLI_STATUS Sdpf (standard,developer,perl,functions)
MANPAGE ExtUtils::Embed - Utilities for embedding Perl in C/C++
applications
INST_FILE /home/stas/perl/5.6.1/lib/5.6.1/ExtUtils/Embed.pm
INST_VERSION 1.2505
Though I can't quite figure out how that objects becomes an argument to catdir.
--
__________________________________________________________________
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: [mp2] recent 5.6.x breakage
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 29 Jun 2004, Stas Bekman wrote:
> It seems that perl 5.6.x is no longer working with mp2, and that's a pretty
> recent breakage I believe.
>
> The server fails to start:
>
> Cannot load
> /home/stas/apache.org/mp2-pool/src/modules/perl/mod_perl.so into
> server: /home/stas/apache.org/mp2-pool/src/modules/perl/mod_perl.so:
> undefined symbol: boot_DynaLoader
>
> This happens because
>
> my $ldopts = ExtUtils::Embed::ldopts();
>
> from Apache::Build doesn't get Dynaloader.a included. This in turn happens
> because something happens to catdir. In ExtUtils::Embed::ldopts, the line
>
> $root = $MM->catdir(@ns);
>
> passes "DynaLoader" as the only contents of @ns, but catdir receives
> some bogus object parameter: MY=HASH(0x9379394)
>
> Here is the output from debuger:
>
> DB<4> n
> ExtUtils::Embed::ldopts(/home/stas/perl/5.6.1/lib/5.6.1/ExtUtils/Embed.pm:188):
> 188: $root = $MM->catdir(@ns);
>
> DB<4> p $sub
> DynaLoader
>
> DB<5> p @ns
> DynaLoader
>
> DB<6> s
> File::Spec::Functions::CODE(0x81e9664)(/home/stas/perl/5.6.1/lib/5.6.1/File/Spec/Functions.pm:41):
> 41: *{$meth} = sub {&$sub('File::Spec', @_)};
>
> DB<6> p "@_"
> MY=HASH(0x9379394) DynaLoader
>
> Someone messes with catdir, but I can't figure out where does this
> happen.
>
> Randy, is it possible that some recent win32 changes have caused that?
> I see that problem on linux, but is it possible that some catdir
> override has happened?
Hi Stas,
Although anything's possible, of course, I don't see at the
moment where this happened due to recent win32 changes. The
changes concerning decoupling APR from mod_perl specific to
Win32 were all wrapped around if(WIN32) {}, except for
building xs/APR/aprext/, which should do nothing on
non-Win32, as the dynamic and static targets were skipped.
Before this sequence of changes there were some Win32 ones
in the tests, but these probably are irrelevant to this
problem.
Unfortunately, I don't have a perl-5.6 available (except
for a Win32 one, but that can't build mp2). Do you know if
it was working before I committed your large patch for
decoupling APR from mod_perl.so (before any of the Win32
stuff was put in)?
I looked at my ExtUtils::Embed. One, version 1.2505, has
$root = $MM->catdir(@ns);
where
my $MM = bless {} => 'MY';
from a few lines earlier. Perhaps the stray MY object
reference is related to this "MY". Can you see what
happens if you upgrade ExtUtils::Embed - version
1.25061 has the corresponding line
$root = File::Spec->catdir(@ns);
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org