Re: need your help to test mod_perl with perl-5.8.1-RC3
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
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[EMAIL PROTECTED] http://www.pobox.com/~schwern/
I'm exploring my nipples.
Re: need your help to test mod_perl with perl-5.8.1-RC3
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
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[EMAIL PROTECTED] 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
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
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[EMAIL PROTECTED] 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
Michael G Schwern [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 'Subject: PATCH: lib/ExtUtils/ty' Change 15534 on 2002/03/26 by [EMAIL PROTECTED] 'Subject: Re: [PATCH] STRLEN typ' Change 11621 on 2001/08/09 by [EMAIL PROTECTED] 'Subject: [PATCH] remove PL_na f' Change 9737 on 2001/04/18 by [EMAIL PROTECTED] 'Subject: [PATCH] XS::Typemap - ' Change 9553 on 2001/04/05 by [EMAIL PROTECTED] 'Integrate changes #9544,9547,95' Change 9437 on 2001/03/29 by [EMAIL PROTECTED] 'Subject: [PATCH [EMAIL PROTECTED] type' Change 9380 on 2001/03/27 by [EMAIL PROTECTED] 'Subject: [PATCH] Typemap testin' Change 8934 on 2001/02/25 by [EMAIL PROTECTED] 'Integrate perlio: [ 8927] Cha' Change 8359 on 2001/01/08 by [EMAIL PROTECTED] 'Integrate perlio: [ 8356] FIL' Change 8308 on 2001/01/04 by [EMAIL PROTECTED] 'Subject: [patch] typemap =~ s/c' Change 6918 on 2000/08/30 by [EMAIL PROTECTED] 'NVs not necessarily doubles, as' Change 6915 on 2000/08/30 by [EMAIL PROTECTED] 'Subject: [PATCH] fix misc cast ' Change 6122 on 2000/05/28 by [EMAIL PROTECTED] 'downgrade fatal error on Cfoo' Change 4255 on 1999/09/30 by [EMAIL PROTECTED] 'remove prehistoric XFree() gunk' Change 4142 on 1999/09/13 by [EMAIL PROTECTED] 'integrate cfgperl contents into' Change 4106 on 1999/09/08 by [EMAIL PROTECTED] 'integrate cfgperl contents into' Change 3622 on 1999/07/06 by [EMAIL PROTECTED] 'applied patch after demunging h' Change 3524 on 1999/06/09 by [EMAIL PROTECTED] 'more complete support for impli' Change 2326 on 1998/11/27 by [EMAIL PROTECTED] 'integrate changes#2304,2305,230' Change 1578 on 1998/07/20 by [EMAIL PROTECTED] 'complete s/foo/PL_foo/ changes ' Change 1575 on 1998/07/20 by [EMAIL PROTECTED] 'integrate ansi branch to get s/' Change 822 on 1998/03/16 by [EMAIL PROTECTED] 'Bump patchlevel.h to 63. ' Change 496 on 1998/02/11 by [EMAIL PROTECTED] 'Integrate win32 into mainline. ' Change 457 on 1998/02/03 by [EMAIL PROTECTED] 'Integrate win32 into mainline. ' Change 439 on 1998/01/27 by [EMAIL PROTECTED] 'Integrate ansi branch into main' Change 296 on 1997/11/25 by [EMAIL PROTECTED] 'Integrate from ansi branch to m' Change 77 on 1997/09/29 by [EMAIL PROTECTED] 'Start merge with maint-5.004 br' Change 18 on 1997/05/25 by [EMAIL PROTECTED] 'First stab at 5.003 - 5.004 in' Change 1 on 1997/03/28 by [EMAIL PROTECTED] 'Perl 5.003 check-in '
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 01:27:01PM -0700, Michael G Schwern wrote: 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. Actually, try 6.13. That snapshot had a bug in it. -- Abandon failing tactics.
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 makefiles.tar.gz Description: GNU Zip compressed data
Re: need your help to test mod_perl with perl-5.8.1-RC3
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
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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, now that I've had a day or so to play with it (using both worker and prefork), I have yet to see any issues. It looks good. However, any further testing I do will probably be limited to prefork, since the overhead of ithreads manages to eat all the memory on my workstation. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KuSoA4aoazQ9p2cRAiDAAKDxbLR17B4R/2w8tD56aKTcKlQ8EgCgo8B0 ICKCbkeKlf6Xe/WE7bwlpm8= =C6/k -END PGP SIGNATURE-
Re: need your help to test mod_perl with perl-5.8.1-RC3
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
Re: need your help to test mod_perl with perl-5.8.1-RC3
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
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
Stephen Clouse wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 30, 2003 at 11:15:32PM +0200, Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. The only problem so far is the ithreads mod_perl takes three glacial eons to start issue. You brought that up on modperl-dev a few days ago but I haven't had a chance to rebuild everything with ithreads until now. Did you ever hear anything from Arthur? That was a different though related issue. since mod_perl's test suite is huge (loads about 100 test modules + about 50 normal modules) it takes a long time to copy the mutable data when creating a new perl clone. That should be fixed when perl implements COW (copy-on-write), so it'll work similar to the OS-level sharing. However this won't happen in 5.8.1 :( __ 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
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. BAD NEWS: There seems to be a problem with ExtUtils-MakeMaker 6.12 included in perl-5.8.1-RC3. I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl as well, and found that it doesn't build. I get the following error: ... link -out:..\blib\arch\auto\libapreq\libapreq.dll ... libapreq.def : error LNK2001: unresolved external symbol boot_libapreq If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in perl-5.8.0) then it it's all OK. The question is: why is it trying to build libapreq.dll? It should only build Request.dll and Cookie.dll, which would probably explain why boot_libapreq is undefined. I'll continue looking into it myself, and can supply more info to anyone that wants it, but I thought I'd better raise the alarm quickly first. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. BAD NEWS: There seems to be a problem with ExtUtils-MakeMaker 6.12 included in perl-5.8.1-RC3. I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl as well, and found that it doesn't build. I get the following error: ... link -out:..\blib\arch\auto\libapreq\libapreq.dll ... libapreq.def : error LNK2001: unresolved external symbol boot_libapreq If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in perl-5.8.0) then it it's all OK. The question is: why is it trying to build libapreq.dll? It should only build Request.dll and Cookie.dll, which would probably explain why boot_libapreq is undefined. I'll continue looking into it myself, and can supply more info to anyone that wants it, but I thought I'd better raise the alarm quickly first. I have a similar problem on linux, Request.so dynamically links libapreq.so, which subsequently can't be found. I'm looking at it. __ 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
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 31, 2003 at 11:41:42AM +0200, Stas Bekman wrote: Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. *** mod_perl version 1.9910 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS= /opt/apache/bin/apxs MP_COMPAT_1X = MP_DEBUG = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_MAINTAINER = 1 MP_TRACE = 1 MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /opt/apache/bin/httpd -V Server version: Apache/2.0.47 Server built: Jul 30 2003 17:58:08 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/opt/apache -D SUEXEC_BIN=/opt/apache/bin/suexec -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /opt/perl/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.20-19.8, archname=i686-linux-thread-multi uname='linux stephenc.theiqgroup.com 2.4.20-19.8 #1 tue jul 15 15:25:37 edt 2003 i686 i686 i386 gnulinux ' config_args='-des -Dprefix=/opt/perl -Dinstallprefix=/opt/perl -Dvendorprefix=/opt/perl -Dsiteprefix=/opt/perl -Dmyhostname=localhost [EMAIL PROTECTED] -Dcf_by=IQG-SPC -Dcc=gcc -Doptimize=-O3 -march=i686 -mcpu=i686 -ggdb3 -Duseshrplib -Duseperlio -Dusethreads -Duseithreads -Dusemymalloc' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 -march=i686 -mcpu=i686 -ggdb3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing' ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/opt/perl/lib/5.8.1/i686-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: RC3 Built under linux Compiled at Jul 30 2003 17:12:12 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /opt/perl/lib/5.8.1/i686-linux-thread-multi /opt/perl/lib/5.8.1 /opt/perl/lib/site_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/site_perl/5.8.1 /opt/perl/lib/site_perl /opt/perl/lib/vendor_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/vendor_perl/5.8.1 /opt/perl/lib/vendor_perl . Unfortunately a couple of the modules we're using don't want to cooperate with ithreads (XML::GDOME is a notable one). I'm working on patches for these; in the meantime, I'll at least give it a thorough run-through with prefork. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KZcHA4aoazQ9p2cRAmaXAKCIE5sROjyScppt8qu47Pm7LJw6kgCfajBU 1E4cCfuKlCnKzdwCuQVzUzw= =H4RV -END PGP SIGNATURE-
Re: need your help to test mod_perl with perl-5.8.1-RC3
Here is what happens:
MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a
by product and never was intented to be installed. Request.so was statically
linking libapreq.a into it.
Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so
is linked, it links libapreq.so dynamically, and of course it can't resolve it
later when loading.
This patch fixes things for me in libapreq and works with MM 6.03 and 6.12.
Steve, please confirm that it works for you and I'll commit it.
However Michael may want to do something else about it, since the two versions
don't do the same thing. And other people may have similar problems.
Index: Cookie/Makefile.PL
===
RCS file: /home/cvs/httpd-apreq/Cookie/Makefile.PL,v
retrieving revision 1.5
diff -u -r1.5 Makefile.PL
--- Cookie/Makefile.PL 3 Apr 2001 19:24:08 - 1.5
+++ Cookie/Makefile.PL 31 Jul 2003 11:31:06 -
@@ -27,7 +27,7 @@
@mm_args,
'INC' = -I../c . $src-inc,
'TYPEMAPS' = $src-typemaps,
-'LIBS' = -L$root -lapreq,
+'OBJECT' = Cookie.o $root/libapreq.a,
'dynamic_lib' = {
'OTHERLDFLAGS' = $src-otherldflags,
},
Index: Request/Makefile.PL
===
RCS file: /home/cvs/httpd-apreq/Request/Makefile.PL,v
retrieving revision 1.5
diff -u -r1.5 Makefile.PL
--- Request/Makefile.PL 3 Apr 2001 19:24:09 - 1.5
+++ Request/Makefile.PL 31 Jul 2003 11:31:06 -
@@ -27,7 +27,7 @@
@mm_args,
'INC' = -I../c . $src-inc,
'TYPEMAPS' = $src-typemaps,
- 'LIBS' = -L$root -lapreq,
+ 'OBJECT' = Request.o $root/libapreq.a,
'dynamic_lib' = {
'OTHERLDFLAGS' = $src-otherldflags,
},
__
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
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. It seems likely that if my build ever got as far as trying to build Request.dll then it would fail without your patch, and your patch would fix that bit, but at the moment I'm not getting that far. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. I think the cause is the same. MM 6.12 builds the shared object of libapreq (dll in your case and .so in mine), and it didn't use to do that. It seems likely that if my build ever got as far as trying to build Request.dll then it would fail without your patch, and your patch would fix that bit, but at the moment I'm not getting that far. Let me see if I can make it skip building the shared object with 6.12, which will resolve the problem for you as well. __ 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
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. I think the cause is the same. MM 6.12 builds the shared object of libapreq (dll in your case and .so in mine), and it didn't use to do that. OK, try this patch: Index: c/Makefile.PL === RCS file: /home/cvs/httpd-apreq/c/Makefile.PL,v retrieving revision 1.7 diff -u -r1.7 Makefile.PL --- c/Makefile.PL 3 Apr 2001 19:24:12 - 1.7 +++ c/Makefile.PL 31 Jul 2003 13:20:35 - @@ -18,7 +18,7 @@ WriteMakefile( #grr, problems with things finding libapreq.so, sort out later. 'LINKTYPE' = 'static', -# 'SKIP' = [qw(dynamic_lib dynamic_bs)], + 'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)], 'NAME' = 'libapreq', 'INC'= $src-inc, 'TYPEMAPS' = $src-typemaps, __ 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
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Here is what happens:
MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a
was just a by product and never was intented to be installed.
Request.so was statically linking libapreq.a into it.
Now with 6.12 it creates both libapreq.so and libapreq.so, so
when Request.so is linked, it links libapreq.so dynamically, and
of course it can't resolve it later when loading.
This patch fixes things for me in libapreq and works with MM 6.03
and 6.12. Steve, please confirm that it works for you and I'll
commit it.
No, it doesn't fix it :-(
My problem sounds a little different to yours. You talk above
about ... when Request.so is linked..., but my build process
doesn't get that far.
Under MM 6.03 it used to build libapreq.lib, then Request.dll then
Cookie.dll.
Now, under MM 6.12, it builds libapreq.lib, then falls over
(boot_libapreq unresolved) when trying to build libapreq.dll.
I think the cause is the same. MM 6.12 builds the shared object of
libapreq (dll in your case and .so in mine), and it didn't use to
do that.
OK, try this patch:
No, still doesn't fix it :-(
Doesn't seem to make any difference, actually. It still tries to
build libapreq.dll, and still fails in the same way. I've attached
the c/Makefile that was generated by the patched c/Makefile.PL (which
should have skipped the dynamic_* bits, but seems not to have done).
But it never received the SKIP argument, from your Makefile:
# MakeMaker Parameters:
# INC = q[ -IC:/apache/include
-IC:/apache/include/../os/win32
-IC:/Temp/mod_perl-1.28/src/modules/perl ]
# NAME = q[libapreq]
# OBJECT = q[apache_request.o apache_cookie.o
apache_multipart_buffer.o]
# TYPEMAPS = [q[C:/Temp/mod_perl-1.28/src/modules/perl/typemap]]
# VERSION = q[1.2]
ah, of course c/Makefile.PL has a special case for WIN32. Try this:
G.
OK, that's better, but it now falls over saying don't know how to make
'dynamic'!
This patch finally fixes it for me:
--- Makefile.PL.orig2001-04-03 20:24:12.0 +0100
+++ Makefile.PL2003-07-31 15:17:03.0 +0100
@@ -18,7 +18,7 @@
WriteMakefile(
#grr, problems with things finding libapreq.so, sort out later.
'LINKTYPE' = 'static',
-# 'SKIP' = [qw(dynamic_lib dynamic_bs)],
+ 'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'NAME' = 'libapreq',
'INC' = $src-inc,
'TYPEMAPS' = $src-typemaps,
@@ -67,6 +67,8 @@
WriteMakefile('NAME' = 'libapreq',
'TYPEMAPS' = [ $ENV{MP_INC}/typemap ],
'VERSION' = $myVERSION,
+'LINKTYPE' = 'static',
+'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'OBJECT' = @objs,
'INC' = qq{ -I$ENV{AP_INC}
-I$ENV{AP_INC}/../os/win32 -I$ENV{MP_INC} },
);
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
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. 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. -- You're the sickest teenager I've ever set my wallet on.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Jarkko's original post had the links wrong: Here are the right links: http://www.iki.fi/jhi/perl-5.8.1-RC3.tar.bz http://www.iki.fi/jhi/perl-5.8.1-RC3.tar.gz or rsync -avz ftp.linux.activestate.com::perl-5.8.x perl-5.8.x You might also want to read the perldelta online: http://www.iki.fi/jhi/perldelta-RC3.html __ 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
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 30, 2003 at 11:15:32PM +0200, Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. The only problem so far is the ithreads mod_perl takes three glacial eons to start issue. You brought that up on modperl-dev a few days ago but I haven't had a chance to rebuild everything with ithreads until now. Did you ever hear anything from Arthur? Anyway, now I'm off to load some production code into it and see how it fares. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KF+bA4aoazQ9p2cRAqxdAJ9T/BOqg4jNo25vay1PzIRe+hM8jgCgwbI9 dmGE6oAn+TRiL+ZYRfsKzhY= =HsN4 -END PGP SIGNATURE-
