You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Steve Hay <st...@uk.radan.com> on 2003/08/01 10:05:55 UTC
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote:
>On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote:
>
>
>>This patch finally fixes it for me:
>>
>>
>
>I'm glad you guys got it working, but there's still the problem of why
>MakeMaker's behavior changed. Since I tend not to touch the XS building
>code much its likely a bug. Try the snapshot on makemaker.org. I just
>fixed a minor issue with argument passing in recursive builds.
>
I just tried MM 6.13: that made no difference.
Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed
loads of its own tests, but made no difference to the libapreq build
process.
>
>If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out
>what's different. Also, if you could try various alpha versions between
>those two, show the Makefiles and whether or not they exhibited the
>behavior that would help alot in narrowing it down.
>
>
I've also tried MM 6.05: that works OK.
Attached are the various Makefiles (the top-level one, plus those from
the c, Cookie and Request sub-directories), and a transcript of the
"nmake" step, from a build using MM 6.05 (which worked) and another
build using MM 6.12 (which failed).
I'll move on to trying out those alpha versions and get back to you on
which was the first one that failed.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Michael G Schwern <sc...@pobox.com>.
On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote:
> Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?
typemap is very specific to the version of Perl, or so it is said.
--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
You're more radiant than a memory of breathtaking ecstasy.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Nick Ing-Simmons <ni...@ing-simmons.net>.
Michael G Schwern <sc...@pobox.com> writes:
>On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote:
>> Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?
>
>typemap is very specific to the version of Perl, or so it is said.
Not really. There are some changes for PerlIO * vs FILE *
but other than that I am unaware of anything significant in years.
(But then so long as it works I don't look)...
Okay here are changes that have touched typemap in the mainline:
Change 17989 on 2002/10/10 by hv@hv-crypt.org 'Subject: PATCH: lib/ExtUtils/ty'
Change 15534 on 2002/03/26 by jhi@alpha 'Subject: Re: [PATCH] STRLEN typ'
Change 11621 on 2001/08/09 by jhi@alpha 'Subject: [PATCH] remove PL_na f'
Change 9737 on 2001/04/18 by jhi@alpha 'Subject: [PATCH] XS::Typemap - '
Change 9553 on 2001/04/05 by jhi@alpha 'Integrate changes #9544,9547,95'
Change 9437 on 2001/03/29 by jhi@alpha 'Subject: [PATCH perl@9424] type'
Change 9380 on 2001/03/27 by jhi@alpha 'Subject: [PATCH] Typemap testin'
Change 8934 on 2001/02/25 by jhi@alpha 'Integrate perlio: [ 8927] Cha'
Change 8359 on 2001/01/08 by jhi@alpha 'Integrate perlio: [ 8356] FIL'
Change 8308 on 2001/01/04 by jhi@alpha 'Subject: [patch] typemap =~ s/c'
Change 6918 on 2000/08/30 by jhi@alpha 'NVs not necessarily doubles, as'
Change 6915 on 2000/08/30 by jhi@alpha 'Subject: [PATCH] fix misc cast '
Change 6122 on 2000/05/28 by gsar@auger 'downgrade fatal error on C<"foo'
Change 4255 on 1999/09/30 by gsar@auger 'remove prehistoric XFree() gunk'
Change 4142 on 1999/09/13 by gsar@auger 'integrate cfgperl contents into'
Change 4106 on 1999/09/08 by gsar@auger 'integrate cfgperl contents into'
Change 3622 on 1999/07/06 by gsar@sparc26 'applied patch after demunging h'
Change 3524 on 1999/06/09 by gsar@sparc26 'more complete support for impli'
Change 2326 on 1998/11/27 by gsar@aatma 'integrate changes#2304,2305,230'
Change 1578 on 1998/07/20 by gsar@aatma 'complete s/foo/PL_foo/ changes '
Change 1575 on 1998/07/20 by gsar@aatma 'integrate ansi branch to get s/'
Change 822 on 1998/03/16 by mbeattie@localhost 'Bump patchlevel.h to 63. '
Change 496 on 1998/02/11 by mbeattie@localhost 'Integrate win32 into mainline. '
Change 457 on 1998/02/03 by mbeattie@localhost 'Integrate win32 into mainline. '
Change 439 on 1998/01/27 by mbeattie@localhost 'Integrate ansi branch into main'
Change 296 on 1997/11/25 by mbeattie@localhost 'Integrate from ansi branch to m'
Change 77 on 1997/09/29 by mbeattie@localhost 'Start merge with maint-5.004 br'
Change 18 on 1997/05/25 by mbeattie@localhost 'First stab at 5.003 -> 5.004 in'
Change 1 on 1997/03/28 by mbeattie@localhost 'Perl 5.003 check-in '
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote:
>
>
>>Somehow, it has contrived to disappear! It always used to exist there,
>>which is why it didn't occur to me to check :-( I must have lost it
>>somewhere along the line when shoe-horning earlier MakeMaker's into place.
>>
>>
>
>Possibly you deleted the ExtUtils/ directory?
>
Yes, I think I did delete it when installing MM 6.06_01 because its own
Makefile was broken so I couldn't run "nmake install".
I see that Perl's lib/ExtUtils directory contains a typemap and
ExtUtils-MakeMaker's lib/ExtUtils directory doesn't. So that would
explain it.
Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote:
>
>
>>Somehow, it has contrived to disappear! It always used to exist there,
>>which is why it didn't occur to me to check :-( I must have lost it
>>somewhere along the line when shoe-horning earlier MakeMaker's into place.
>>
>>
>
>Possibly you deleted the ExtUtils/ directory?
>
Yes, I think I did delete it when installing MM 6.06_01 because its own
Makefile was broken so I couldn't run "nmake install".
I see that Perl's lib/ExtUtils directory contains a typemap and
ExtUtils-MakeMaker's lib/ExtUtils directory doesn't. So that would
explain it.
Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Michael G Schwern <sc...@pobox.com>.
On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote:
> Somehow, it has contrived to disappear! It always used to exist there,
> which is why it didn't occur to me to check :-( I must have lost it
> somewhere along the line when shoe-horning earlier MakeMaker's into place.
Possibly you deleted the ExtUtils/ directory?
> Having now restored that file, the patch above does indeed fix it for me.
Yay!
--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
I need a SHOWER a BURGER and some ROBOTS, STAT!
-- http://www.angryflower.com/allrigh.gif
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
>
>
>>I tried changing the s/// to:
>>
>> $string =~ s{ \$\(INST_DYNAMIC\)}{}g;
>> $string =~ s{ \$\(INST_BOOT\)}{}g;
>>
>>(I've dropped the trailing spaces in the patterns), which produced:
>>
>>dynamic :: $(FIRST_MAKEFILE)
>> $(NOECHO) $(NOOP)
>>
>>in the Makefile as desired, but now the build process fails with this error:
>>
>>fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
>>
>>
>
>That's odd. Does that file exist? If not, where is your typemap file?
>
>
Somehow, it has contrived to disappear! It always used to exist there,
which is why it didn't occur to me to check :-( I must have lost it
somewhere along the line when shoe-horning earlier MakeMaker's into place.
Having now restored that file, the patch above does indeed fix it for me.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
>
>
>>I tried changing the s/// to:
>>
>> $string =~ s{ \$\(INST_DYNAMIC\)}{}g;
>> $string =~ s{ \$\(INST_BOOT\)}{}g;
>>
>>(I've dropped the trailing spaces in the patterns), which produced:
>>
>>dynamic :: $(FIRST_MAKEFILE)
>> $(NOECHO) $(NOOP)
>>
>>in the Makefile as desired, but now the build process fails with this error:
>>
>>fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
>>
>>
>
>That's odd. Does that file exist? If not, where is your typemap file?
>
>
Somehow, it has contrived to disappear! It always used to exist there,
which is why it didn't occur to me to check :-( I must have lost it
somewhere along the line when shoe-horning earlier MakeMaker's into place.
Having now restored that file, the patch above does indeed fix it for me.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Michael G Schwern <sc...@pobox.com>.
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
> I tried changing the s/// to:
>
> $string =~ s{ \$\(INST_DYNAMIC\)}{}g;
> $string =~ s{ \$\(INST_BOOT\)}{}g;
>
> (I've dropped the trailing spaces in the patterns), which produced:
>
> dynamic :: $(FIRST_MAKEFILE)
> $(NOECHO) $(NOOP)
>
> in the Makefile as desired, but now the build process fails with this error:
>
> fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
I'm exploring my nipples.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
>previous had this:
>
>dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
>
>6.06_01 and up have this
>
>dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
>
>for some reason, MY::dynamic is trying to lop off everything after "Makefile"
>and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
>(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
>/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
>two places.
>
>Coupled with the fact that its set LINKTYPE 'static' with a comment
>"problems with things finding libareq.so, sort out later" leads me to
>believe this was a work around a MakeMaker bug.
>
>Chaning s/(Makefile\s+).*/$1/g to
>s{ \$\(INST_DYNAMIC\) }{}g;
>s{ \$\(INST_BOOT\) }{}g;
>should "fix" the symptoms by restoring the hack for a quick fix.
>
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
>
>For a longer term solution, try removing the MY::dynamic and
>MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
>see what happens.
>
I tried removing MY::dynamic and MY::top_targets, plus *adding* LINKTYPE
'dynamic' to the Win32-specific section. That seems to get me back to
square one - the Makefile contains:
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
and the build fails as it originally did with:
libapreq.def : error LNK2001: unresolved external symbol boot_libapreq
Only the fix previously posted by Stas (adding 'SKIP' => [qw(dynamic
dynamic_lib dynamic_bs)], to both WriteMakefile() calls) works for me so
far, but Joe had a problem that...
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
>previous had this:
>
>dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
>
>6.06_01 and up have this
>
>dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
>
>for some reason, MY::dynamic is trying to lop off everything after "Makefile"
>and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
>(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
>/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
>two places.
>
>Coupled with the fact that its set LINKTYPE 'static' with a comment
>"problems with things finding libareq.so, sort out later" leads me to
>believe this was a work around a MakeMaker bug.
>
>Chaning s/(Makefile\s+).*/$1/g to
>s{ \$\(INST_DYNAMIC\) }{}g;
>s{ \$\(INST_BOOT\) }{}g;
>should "fix" the symptoms by restoring the hack for a quick fix.
>
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
>
>For a longer term solution, try removing the MY::dynamic and
>MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
>see what happens.
>
I tried removing MY::dynamic and MY::top_targets, plus *adding* LINKTYPE
'dynamic' to the Win32-specific section. That seems to get me back to
square one - the Makefile contains:
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
and the build fails as it originally did with:
libapreq.def : error LNK2001: unresolved external symbol boot_libapreq
Only the fix previously posted by Stas (adding 'SKIP' => [qw(dynamic
dynamic_lib dynamic_bs)], to both WriteMakefile() calls) works for me so
far, but Joe had a problem that...
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Michael G Schwern <sc...@pobox.com>.
On Fri, Aug 01, 2003 at 11:35:47AM +0100, Steve Hay wrote:
> =====================
> # --- MakeMaker dynamic section:
> ## $(INST_PM) has been moved to the all: target.
> ## It remains here for awhile to allow for old usage: "make dynamic"
> #dynamic :: Makefile
> dynamic :: Makefile
> @$(NOOP)
> =====================
>
> while the corresponding section from the 6.12 build contains this:
>
> =====================
> # --- MakeMaker dynamic section:
> ## $(INST_PM) has been moved to the all: target.
> ## It remains here for awhile to allow for old usage: "make dynamic"
> dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
> $(NOECHO) $(NOOP)
> =====================
>
> If that's relevant, then the latter looks more likely to be correct,
> doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
> the only problem here is that libapreq was previously relying on that bug?
The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after "Makefile"
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
"problems with things finding libareq.so, sort out later" leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should "fix" the symptoms by restoring the hack for a quick fix.
For a longer term solution, try removing the MY::dynamic and
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
It would be nice if someone could dig through libapreq's version history
and figure out when and why this hack was put in.
--
WOOHOO! I'm going to Disneyland!
http://www.goats.com/archive/980805.html
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
>
>
>>>This bug evidently goes back a long way: MM 6.06_02 fails in the same
>>>way as 6.13.
>>>
>>>I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
>>>how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
>>>place, but when I tried to use it to build libapreq, I just got the
>>>same error again - "don't know how to make 'C:\perl5\libNAME'".
>>>
>>>
>>OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
>>-- needed to change DIRFILESEP from \ to ^\, and fill in the missing
>>*PERLSAFE macros), and the bad news is that it doesn't build
>>libapreq-1.2 either! I still get the "unresolved external symbol
>>boot_libapreq" error.
>>
>>So it's one of the many changes between 6.05 and 6.06_01 that broke it.
>>
>>
>
>Well, that narrows it down quite a bit.
>
>Which version of mod_perl and Apache is this against and *exactly* what do
>I have to do to exercise this bug? I haven't built mod_perl in a long time.
>
>
I'm using Apache 1.3.27, mod_perl 1.28, libapreq-1.2, but I'm on Windows
with MS VC++ 6.0, so this might not be very useful to you since you
haven't got such a setup yourself... Anyway, here goes; it's probably
pretty similar on whatever OS you're on (perhaps with an extra
"./configure ..." line before the Apache "make"?)
- Unpack Apache, mod_perl, libapreq into C:\Temp
- cd to C:\Temp\apache_1.3.27\src
- Run "nmake /f makefile.win installr". That builds Apache and installs
it into C:\apache by default.
- cd to C:\Temp\mod_perl-1.28
- Run "perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules".
- Run "nmake", "nmake test", "nmake install" as usual.
- cd to C:\Temp\libapreq-1.2
- Run "perl Makefile.PL"
- Run "nmake" -- that fails with the "unresolved external symbol
boot_libapreq" error.
That's it.
BTW, I've been looking at the Makefiles that I sent previously, and have
found something interesting. The Makefile in the "c" sub-directory from
the 6.05 build contains this:
=====================
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make dynamic"
#dynamic :: Makefile
dynamic :: Makefile
@$(NOOP)
=====================
while the corresponding section from the 6.12 build contains this:
=====================
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make dynamic"
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
=====================
If that's relevant, then the latter looks more likely to be correct,
doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
the only problem here is that libapreq was previously relying on that bug?
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Michael G Schwern wrote:
>On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
>
>
>>>This bug evidently goes back a long way: MM 6.06_02 fails in the same
>>>way as 6.13.
>>>
>>>I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
>>>how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
>>>place, but when I tried to use it to build libapreq, I just got the
>>>same error again - "don't know how to make 'C:\perl5\libNAME'".
>>>
>>>
>>OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
>>-- needed to change DIRFILESEP from \ to ^\, and fill in the missing
>>*PERLSAFE macros), and the bad news is that it doesn't build
>>libapreq-1.2 either! I still get the "unresolved external symbol
>>boot_libapreq" error.
>>
>>So it's one of the many changes between 6.05 and 6.06_01 that broke it.
>>
>>
>
>Well, that narrows it down quite a bit.
>
>Which version of mod_perl and Apache is this against and *exactly* what do
>I have to do to exercise this bug? I haven't built mod_perl in a long time.
>
>
I'm using Apache 1.3.27, mod_perl 1.28, libapreq-1.2, but I'm on Windows
with MS VC++ 6.0, so this might not be very useful to you since you
haven't got such a setup yourself... Anyway, here goes; it's probably
pretty similar on whatever OS you're on (perhaps with an extra
"./configure ..." line before the Apache "make"?)
- Unpack Apache, mod_perl, libapreq into C:\Temp
- cd to C:\Temp\apache_1.3.27\src
- Run "nmake /f makefile.win installr". That builds Apache and installs
it into C:\apache by default.
- cd to C:\Temp\mod_perl-1.28
- Run "perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules".
- Run "nmake", "nmake test", "nmake install" as usual.
- cd to C:\Temp\libapreq-1.2
- Run "perl Makefile.PL"
- Run "nmake" -- that fails with the "unresolved external symbol
boot_libapreq" error.
That's it.
BTW, I've been looking at the Makefiles that I sent previously, and have
found something interesting. The Makefile in the "c" sub-directory from
the 6.05 build contains this:
=====================
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make dynamic"
#dynamic :: Makefile
dynamic :: Makefile
@$(NOOP)
=====================
while the corresponding section from the 6.12 build contains this:
=====================
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make dynamic"
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
=====================
If that's relevant, then the latter looks more likely to be correct,
doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
the only problem here is that libapreq was previously relying on that bug?
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Michael G Schwern <sc...@pobox.com>.
On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
> >This bug evidently goes back a long way: MM 6.06_02 fails in the same
> >way as 6.13.
> >
> >I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> >how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
> >place, but when I tried to use it to build libapreq, I just got the
> >same error again - "don't know how to make 'C:\perl5\libNAME'".
>
> OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
> -- needed to change DIRFILESEP from \ to ^\, and fill in the missing
> *PERLSAFE macros), and the bad news is that it doesn't build
> libapreq-1.2 either! I still get the "unresolved external symbol
> boot_libapreq" error.
>
> So it's one of the many changes between 6.05 and 6.06_01 that broke it.
Well, that narrows it down quite a bit.
Which version of mod_perl and Apache is this against and *exactly* what do
I have to do to exercise this bug? I haven't built mod_perl in a long time.
--
I'll tell you what beats voodoo every time, a big ass knife.
-- "Overkill" Battlebot driver
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> This bug evidently goes back a long way: MM 6.06_02 fails in the same
> way as 6.13.
>
> I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
> place, but when I tried to use it to build libapreq, I just got the
> same error again - "don't know how to make 'C:\perl5\libNAME'".
OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
-- needed to change DIRFILESEP from \ to ^\, and fill in the missing
*PERLSAFE macros), and the bad news is that it doesn't build
libapreq-1.2 either! I still get the "unresolved external symbol
boot_libapreq" error.
So it's one of the many changes between 6.05 and 6.06_01 that broke it.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> This bug evidently goes back a long way: MM 6.06_02 fails in the same
> way as 6.13.
>
> I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
> place, but when I tried to use it to build libapreq, I just got the
> same error again - "don't know how to make 'C:\perl5\libNAME'".
OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
-- needed to change DIRFILESEP from \ to ^\, and fill in the missing
*PERLSAFE macros), and the bad news is that it doesn't build
libapreq-1.2 either! I still get the "unresolved external symbol
boot_libapreq" error.
So it's one of the many changes between 6.05 and 6.06_01 that broke it.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Michael G Schwern wrote:
>
>
>>
>> If I could see the Makefiles from 6.03 and 6.12 I might be able to
>> figure out
>> what's different. Also, if you could try various alpha versions between
>> those two, show the Makefiles and whether or not they exhibited the
>> behavior that would help alot in narrowing it down.
>>
>>
> I've also tried MM 6.05: that works OK.
>
> Attached are the various Makefiles (the top-level one, plus those from
> the c, Cookie and Request sub-directories), and a transcript of the
> "nmake" step, from a build using MM 6.05 (which worked) and another
> build using MM 6.12 (which failed).
>
> I'll move on to trying out those alpha versions and get back to you on
> which was the first one that failed.
This bug evidently goes back a long way: MM 6.06_02 fails in the same
way as 6.13.
I tried to use MM 6.06_01, but it wouldn't build itself ("don't know how
to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
place, but when I tried to use it to build libapreq, I just got the same
error again - "don't know how to make 'C:\perl5\libNAME'".
So the best I can offer you at this stage is that something between 6.05
and 6.06_02 broke it. (Probably not what you wanted to hear, I guess,
looking at the number of changes in 6.06_01.)
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Michael G Schwern wrote:
>
>
>>
>> If I could see the Makefiles from 6.03 and 6.12 I might be able to
>> figure out
>> what's different. Also, if you could try various alpha versions between
>> those two, show the Makefiles and whether or not they exhibited the
>> behavior that would help alot in narrowing it down.
>>
>>
> I've also tried MM 6.05: that works OK.
>
> Attached are the various Makefiles (the top-level one, plus those from
> the c, Cookie and Request sub-directories), and a transcript of the
> "nmake" step, from a build using MM 6.05 (which worked) and another
> build using MM 6.12 (which failed).
>
> I'll move on to trying out those alpha versions and get back to you on
> which was the first one that failed.
This bug evidently goes back a long way: MM 6.06_02 fails in the same
way as 6.13.
I tried to use MM 6.06_01, but it wouldn't build itself ("don't know how
to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
place, but when I tried to use it to build libapreq, I just got the same
error again - "don't know how to make 'C:\perl5\libNAME'".
So the best I can offer you at this stage is that something between 6.05
and 6.06_02 broke it. (Probably not what you wanted to hear, I guess,
looking at the number of changes in 6.06_01.)
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Posted by Michael G Schwern <sc...@pobox.com>.
On Fri, Aug 01, 2003 at 09:05:55AM +0100, Steve Hay wrote:
> I just tried MM 6.13: that made no difference.
>
> Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed
> loads of its own tests, but made no difference to the libapreq build
> process.
Oh yeah, I didn't update the snapshot. Thanks for the reminder.
--
You can't control the universe with a jar of red pepper.
http://www.goats.com/archive/981004.html