Re: Compilation error for CentOS 5.5, perl-5.10, mp2-current
Hi Philip, thanks for looking into it. The version i used here is 2.0.6-dev, the -latest or -current version downloadable from the website. I can pull svn HEAD too and try that. The error is happening in 2.0.4 which i tried first, then i downloaded 2.0.5 because i read of 5.10 improvements and am now using the -current version. alex Am 22.02.2011 um 03:35 schrieb Philip M. Gollucci: On 2/21/2011 12:32 PM, Alexander Goller wrote: Apache2: - Apache2::Request : - CGI: 3.49 ExtUtils::MakeMaker: 6.56, 6.56 LWP: 5.836 mod_perl : - mod_perl2 : - Can you pull the specific version from mod_perl2.pm? Can you try with the recent 2.0.5 and/or svn trunk if thats not what you have. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -- Alexander Goller - Fotografie web: www.ryte.de mail: a...@ryte.de GeSichtweisen - http://gesichtweisen.com/
Re: Compilation error for CentOS 5.5, perl-5.10, mp2-current
On Monday, February 21, 2011 18:32:56 Alexander Goller wrote:
i have a problem compiling mod_perl on CentOS, using perl 5.10.
The problem could have been sorted out on IRC. Alex had used the wrong version
of ExtUtils::Embed.
We can prevent such problems by checking the version with Module::CoreList. Is
it worth the effort?
Module::CoreList has appeared in 5.8.9 and 5.10.0. For earlier versions we can
at least check the ExtUtils::Embed resides somewhere below $Config{privlib}.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Compilation error for CentOS 5.5, perl-5.10, mp2-current
Hi, i have a problem compiling mod_perl on CentOS, using perl 5.10. Bug report: -8-- Start Bug Report 8-- 1. Problem Description: Running make: -c modperl_flags.c mv modperl_flags.o modperl_flags.lo gcc -I/usr/src/redhat/BUILD/modperl-2.0/src/modules/perl -I/usr/src/redhat/BUILD/modperl-2.0/xs -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/include/httpd -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/lib/perl5/CORE -DMOD_PERL -DMP_COMPAT_1X -DLINUX=2 -D_LARGEFILE64_SOURCE -O2 -g -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fPIC \ -c modperl_xsinit.c mv modperl_xsinit.o modperl_xsinit.lo modperl_xsinit.c: In function 'xs_init': modperl_xsinit.c:30: error: 'my_perl' undeclared (first use in this function) modperl_xsinit.c:30: error: (Each undeclared identifier is reported only once modperl_xsinit.c:30: error: for each function it appears in.) modperl_xsinit.c:30: warning: passing argument 3 of 'Perl_newXS' from incompatible pointer type make[1]: *** [modperl_xsinit.lo] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/modperl-2.0/src/modules/perl' make: *** [modperl_lib] Error 2 2. Used Components and their Configuration: *** mod_perl version 2.06 *** using /usr/src/redhat/BUILD/modperl-2.0/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_APXS= /usr/sbin/apxs MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 *** The httpd binary was not found *** (apr|apu)-config linking info -laprutil-1 -lldap -llber -ldb-4.3 -lexpat -lapr-1 -lpthread -ldl *** /usr/bin/perl -V Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=linux, osvers=2.6.18-164.10.1.el5, archname=i386-linux-thread-multi uname='linux master-cent5 2.6.18-164.10.1.el5 #1 smp thu jan 7 20:00:41 est 2010 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -g -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -DDEBUGGING=-g -Accflags=-DPERL_USE_SAFE_PUTENV -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5 -Darchlib=/usr/lib/perl5 -Dvendorarch=/usr/lib/perl5 -Dinc_version_list=5.10.0 -Darchname=i386-linux-thread-multi -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dotherlibdirs=/usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi:/usr/local/lib/perl5/site_perl/5.10.0:/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi:/usr/lib/perl5/vendor_perl:/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-46)', 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 =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.5.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/CORE' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -L/usr/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options
Re: Compilation error for CentOS 5.5, perl-5.10, mp2-current
On 2/21/2011 12:32 PM, Alexander Goller wrote: Apache2: - Apache2::Request : - CGI: 3.49 ExtUtils::MakeMaker: 6.56, 6.56 LWP: 5.836 mod_perl : - mod_perl2 : - Can you pull the specific version from mod_perl2.pm? Can you try with the recent 2.0.5 and/or svn trunk if thats not what you have. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: libapreq2 for Windows, Apache 2.2 and Perl 5.10
Randy Kobes wrote: On Mon, Sep 14, 2009 at 6:54 AM, André Warnier a...@ice-sa.com wrote: Hi. I have tried following the usual links at perl.apache.org, CPAN, ActiveState, and searched Google, but I am getting a bit confused. Is there a binary package available for libapreq2 with ActivePerl 5.10/Apache 2.2/Win32, and if yes, where ? I would have to install this first on a WinXP machine, later on a Win2003 server machine, both 32-bit, on neither of which I have a C compiler available. Is that a problem ? Thanks André There's a libapreq2 ppm package available from http://cpan.uwinnipeg.ca/PPMPackages/10xx/ which should work with this combination. Many thanks. I must have missed something somewhere, but it seemed rather difficult to locate. Starting with perl.apache.org, I remember there used to exist somewhere a link to an mpinstall script to download, but can't find it anymore. Instead there is now somewhere a distinstall, but which did not seem to work in my case (and when examined, only mentions non 5.10 perl versions). There does not seem to exist a proper link between the mod_perl site at perl.apache.org, and an appropriate Win32 perl repository for Apache 2.2 and perl 5.10. Or I missed it.
libapreq2 for Windows, Apache 2.2 and Perl 5.10
Hi. I have tried following the usual links at perl.apache.org, CPAN, ActiveState, and searched Google, but I am getting a bit confused. Is there a binary package available for libapreq2 with ActivePerl 5.10/Apache 2.2/Win32, and if yes, where ? I would have to install this first on a WinXP machine, later on a Win2003 server machine, both 32-bit, on neither of which I have a C compiler available. Is that a problem ? Thanks André
Re: libapreq2 for Windows, Apache 2.2 and Perl 5.10
On Mon, Sep 14, 2009 at 6:54 AM, André Warnier a...@ice-sa.com wrote: Hi. I have tried following the usual links at perl.apache.org, CPAN, ActiveState, and searched Google, but I am getting a bit confused. Is there a binary package available for libapreq2 with ActivePerl 5.10/Apache 2.2/Win32, and if yes, where ? I would have to install this first on a WinXP machine, later on a Win2003 server machine, both 32-bit, on neither of which I have a C compiler available. Is that a problem ? Thanks André There's a libapreq2 ppm package available from http://cpan.uwinnipeg.ca/PPMPackages/10xx/ which should work with this combination. -- best regards, Randy
Re: mod_perl crashes with Perl 5.10
Hi Philippe, (Sorry for the delay with my answer - I'll be quick from now on) Thank you for your interest to help me with this crasher. On Tue, Apr 07, 2009 at 22:17:27 -0400, Philippe M. Chiasson wrote: On 29/3/09 15:30, Jozef Kosoru wrote: Hello, I tested my mod_perl application using following combinations recently: * Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 (default Debian Lenny packages, mpm-prefork) * Apache/2.2.11 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.0 (apache, apreq and mod_perl compiled from sources, mpm-prefork) and I see a crash of Apache process on each request. Just to be sure, is that a 32/64 bit platform ? This is 32 bit. I can check on 64 bit. Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ce0ad0 (LWP 11196)] 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 #1 0xb7bc2dc1 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #2 0xb7bbcd38 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #3 0xb7cb2bfc in modperl_callback (my_perl=0x9ab21a0, handler=0x9639b18, p=0x9ad4578, r=0x9ad45b8, s=0x961bfe0, args=0x98a13c0) at modperl_callback.c:101 Hrm, if at all possible, while in gdb, could you dump more information from that frame ? (gdb) info locals Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7cf9ad0 (LWP 8233)] 0xb7c0b095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 (gdb) info locals No symbol table info available. Any clue? Also, I'd love to see as much of the arguments as possible, expecially handler, r and args (gdb) print *handler (gdb) print *r (gdb) print *args Same with others: (gdb) print *handler No symbol handler in current context. (gdb) print *r No symbol r in current context (gdb) print *args No symbol args in current context Do I have to recompile Perl with some special debug symbols? Thanks. Also, one thing that always help narrow things down is if you could boil down your application to a small enough test case that you could share it with us. I was trying to do so but haven't succeded with any minimalized test-case yet. But it's not really so much code anyway and it's all GPL. I'll try to make an easy package of it. Regards, Jozef -- Jozef Kosoru http://zyzstar.kosoru.com
Re: mod_perl crashes with Perl 5.10
On 29/3/09 15:30, Jozef Kosoru wrote: Hello, I tested my mod_perl application using following combinations recently: * Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 (default Debian Lenny packages, mpm-prefork) * Apache/2.2.11 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.0 (apache, apreq and mod_perl compiled from sources, mpm-prefork) and I see a crash of Apache process on each request. Just to be sure, is that a 32/64 bit platform ? Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ce0ad0 (LWP 11196)] 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 #1 0xb7bc2dc1 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #2 0xb7bbcd38 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #3 0xb7cb2bfc in modperl_callback (my_perl=0x9ab21a0, handler=0x9639b18, p=0x9ad4578, r=0x9ad45b8, s=0x961bfe0, args=0x98a13c0) at modperl_callback.c:101 Hrm, if at all possible, while in gdb, could you dump more information from that frame ? (gdb) info locals Also, I'd love to see as much of the arguments as possible, expecially handler, r and args (gdb) print *handler (gdb) print *r (gdb) print *args Thanks. Also, one thing that always help narrow things down is if you could boil down your application to a small enough test case that you could share it with us. -- Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/ signature.asc Description: OpenPGP digital signature
mod_perl crashes with Perl 5.10
Hello, I tested my mod_perl application using following combinations recently: * Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 (default Debian Lenny packages, mpm-prefork) * Apache/2.2.11 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.0 (apache, apreq and mod_perl compiled from sources, mpm-prefork) and I see a crash of Apache process on each request. Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ce0ad0 (LWP 11196)] 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 #1 0xb7bc2dc1 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #2 0xb7bbcd38 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #3 0xb7cb2bfc in modperl_callback (my_perl=0x9ab21a0, handler=0x9639b18, p=0x9ad4578, r=0x9ad45b8, s=0x961bfe0, args=0x98a13c0) at modperl_callback.c:101 #4 0xb7cb32d3 in modperl_callback_run_handlers (idx=6, type=4, r=0x9ad45b8, c=0x0, s=0x961bfe0, pconf=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:262 #5 0xb7cb39ca in modperl_callback_per_dir (idx=6, r=0x9ad45b8, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:369 #6 0xb7cac6ef in modperl_response_handler_run (r=0x9ad45b8, finish=1) at mod_perl.c:1000 #7 0xb7caca74 in modperl_response_handler (r=0x9ad45b8) at mod_perl.c:1044 #8 0x0807c109 in ap_run_handler (r=0x9ad45b8) at config.c:158 #9 0x0807f469 in ap_invoke_handler (r=0x9ad45b8) at config.c:372 #10 0x08098c06 in ap_process_request (r=0x9ad45b8) at http_request.c:282 #11 0x08095ca8 in ap_process_http_connection (c=0x9ace738) at http_core.c:190 #12 0x08083479 in ap_run_process_connection (c=0x9ace738) at connection.c:43 #13 0x080a9f35 in child_main (child_num_arg=value optimized out) at prefork.c:650 #14 0x080aa213 in make_child (s=0x961bfe0, slot=0) at prefork.c:746 #15 0x080ab018 in ap_mpm_run (_pconf=0x96050a8, plog=0x9641198, s=0x961bfe0) at prefork.c:881 #16 0x08068df0 in main (argc=Cannot access memory at address 0x0 ) at main.c:740 From the perl code perspective it looks like it crashes somewhere inside HTML::Template::output method. I tried several different versions of HTML::Template package and all of them crash in the same way. (However I don't think that the crash is caused by this package.) Last known working mod_perl combination where my application worked just fine is: Apache/2.2.8 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.3 Perl/v5.8.8 (any older versions also worked with no problems) and therefore it seems like an upgrade to Perl 5.10 is a possible reason for this crash. I'm not able to reproduce this problem with a simple hello world application but my application isn't that complicated either. Has anyone experienced a similar issue? I have a very limited experience with debugging of mod_perl/perl crashes. Any advise on how to efficiently track this problem would be greatly appreciated. Thank you. Jozef -- Jozef Kosoru
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
On Mon, Mar 23, 2009 at 5:20 PM, andynic andynic...@yahoo.com wrote: I would like to write a cgi script using a persistent database connection. I have read that I need For database persistent connections: http://cpan.uwinnipeg.ca/dist/Apache-DBI-Cache No, you don't. You don't need anything other than DBI with connect_cached, but you can optionally use the extra features in Apache::DBI. - Perrin
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
Thanks for this. I pretty new at this stuff. I will give it a try. Andynic. andynic wrote: Hi, I have installed on my Windows XP computer: Apache 2.2 Perl 5.10, mod_perl 2 MySql 5.10. I would like to write a cgi script using a persistent database connection. I have read that I need For database persistent connections: http://cpan.uwinnipeg.ca/dist/Apache-DBI-Cache There I find downloads but not for Windows which requires a ppm version. Would anyone know where I can find the Apache-DBI-Cache for the above-mentioned set of software for installation via ppm on Windows XP. Thanks for your help. Andynic. -- View this message in context: http://www.nabble.com/Apache-2.2%2C-perl-5.10%2C-Windows-XP%2C-Apache-DBI-cache-tp22669395p22679396.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
Concerning Rany's reply: I was able to install it with the following command: C:\ppm install http://trouchelle.com/ppm10/Apache-DBI-Cache.ppd Downloading Apache-DBI-Cache-0.08...done Unpacking Apache-DBI-Cache-0.08...done Generating HTML for Apache-DBI-Cache-0.08...done Updating files in site area...done 7 files installed -- View this message in context: http://www.nabble.com/Apache-2.2%2C-perl-5.10%2C-Windows-XP%2C-Apache-DBI-cache-tp22669395p22679473.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Apache 2.2, perl 5.10, Windows XP, Apache-DBI-cache
On Mon, Mar 23, 2009 at 4:20 PM, andynic andynic...@yahoo.com wrote: Hi, I have installed on my Windows XP computer: Apache 2.2 Perl 5.10, mod_perl 2 MySql 5.10. I would like to write a cgi script using a persistent database connection. I have read that I need For database persistent connections: http://cpan.uwinnipeg.ca/dist/Apache-DBI-Cache There I find downloads but not for Windows which requires a ppm version. Would anyone know where I can find the Apache-DBI-Cache for the above-mentioned set of software for installation via ppm on Windows XP. Thanks for your help. Andynic. At the bottom of http://cpan.uwinnipeg.ca/~opi/Apache-DBI-Cache there's links to Win32 repositories which contain this package; from this, the http://trouchelle.com/perl/ppmrepview.pl repository looks like it has it. -- best regards, Randy
Re: Apache::Reload - ModPerl::Util::unload_package under perl 5.10 use base directive malfunction
On 26/12/08 20:39, David Ihnen wrote:
1. Problem Description:
While developing with CGI::Application and utilizing Apache::Reload, we
encountered an issue where our modules were not being succesfully
reinitialized on reload. It was traced down to @ISA not containing the
proper values after a 'use base' directive, but only on automatic
reload, and freshly on perl 5.10, not our previous version of perl 5.8.8!
I determined that when ModPerl::Util::unload_package is used to unload a
package, when it is then re-required in perl 5.10, 'use base' directives
don't function as expected.
I recreated the problem with this simple use case. It happens when a
sub-module (required by something else) is unloaded then re-required. I
included the workaround using the push @ISA method to contrast working
with not working.
This is the output when the program below is run.
$ perl t.pl
X
X
V
Not a CODE reference at t.pl line 14.
Where did the inheritance go after the require of v? Is this a bug in
the do-file functionality utilized by require? Did
ModPerl::Util::unload_package not do something it was supposed to? Is
there a subtle interaction between 5.10 and ModPerl::Util?
I was initially going to submit this to the perl bug database, but
realized that the unload_package function was a ModPerl functionality,
so this is my first place to go. Five files to test with itemized
below. As you can see, I can recreate it without utilizing the mod_perl
environment specifically.
--- begin t.pl ---
#!/usr/bin/perl
use ModPerl::Util;
# Using push @ISA
require w;
w-x();
ModPerl::Util::unload_package('w');
require w;
w-x();
# Using use base
require u;
u-v();
ModPerl::Util::unload_package('v');
require u;
This is strange, as you are unloading 'v' and reloading 'u', probably not
what was intended.
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
Re: Apache::Reload - ModPerl::Util::unload_package under perl 5.10 use base directive malfunction
David Ihnen wrote: 1. Problem Description: While developing with CGI::Application and utilizing Apache::Reload, we encountered an issue where our modules were not being succesfully reinitialized on reload. It was traced down to @ISA not containing the proper values after a 'use base' directive, but only on automatic reload, and freshly on perl 5.10, not our previous version of perl 5.8.8! Are you able to try 5.8.9, its at least a smaller change set to look at if 5.8.9 breaks too. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Director IT - RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Apache::Reload - ModPerl::Util::unload_package under perl 5.10 use base directive malfunction
1. Problem Description:
While developing with CGI::Application and utilizing Apache::Reload, we
encountered an issue where our modules were not being succesfully
reinitialized on reload. It was traced down to @ISA not containing the
proper values after a 'use base' directive, but only on automatic
reload, and freshly on perl 5.10, not our previous version of perl 5.8.8!
I determined that when ModPerl::Util::unload_package is used to unload a
package, when it is then re-required in perl 5.10, 'use base' directives
don't function as expected.
I recreated the problem with this simple use case. It happens when a
sub-module (required by something else) is unloaded then re-required. I
included the workaround using the push @ISA method to contrast working
with not working.
This is the output when the program below is run.
$ perl t.pl
X
X
V
Not a CODE reference at t.pl line 14.
Where did the inheritance go after the require of v? Is this a bug in
the do-file functionality utilized by require? Did
ModPerl::Util::unload_package not do something it was supposed to? Is
there a subtle interaction between 5.10 and ModPerl::Util?
I was initially going to submit this to the perl bug database, but
realized that the unload_package function was a ModPerl functionality,
so this is my first place to go. Five files to test with itemized
below. As you can see, I can recreate it without utilizing the mod_perl
environment specifically.
--- begin t.pl ---
#!/usr/bin/perl
use ModPerl::Util;
# Using push @ISA
require w;
w-x();
ModPerl::Util::unload_package('w');
require w;
w-x();
# Using use base
require u;
u-v();
ModPerl::Util::unload_package('v');
require u;
u-v();
-- end t.pl --
--- begin u.pm ---
package u;
use v;
use base 'v';
1;
--- end u.pm
--- begin v.pm ---
package v;
sub v { print V\n;}
1;
--- end v.pm
--- begin w.pm ---
package w;
use x;
BEGIN { push @ISA, 'x'; }
1;
--- end w.pm
--- begin x.pm ---
package x;
sub x {print X\n;}
1;
--- end x.pm
2. Used Components and their Configuration:
*** mod_perl version 2.04
*** using /usr/lib/perl5/Apache2/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB = aprext
MP_APXS= /usr/bin/apxs2
MP_CCOPTS = -g -Wall
MP_COMPAT_1X = 1
MP_GENERATE_XS = 1
MP_INCLUDE_DIR = /usr/include/apache2 /usr/include/apr-1.0
MP_LIBNAME = mod_perl
MP_TRACE = 0
MP_USE_DSO = 1
MP_USE_GTOP= 1
MP_USE_STATIC = 0
*** The httpd binary was not found
*** (apr|apu)-config linking info
-L/usr/lib -laprutil-1
-L/usr/lib -lapr-1 -luuid -lrt -lcrypt -lpthread -ldl
*** /usr/bin/perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
Platform:
osname=linux, osvers=2.6.24-16-server,
archname=x86_64-linux-gnu-thread-multi
uname='linux yellow 2.6.24-16-server #1 smp thu apr 10 13:15:38 utc
2008 x86_64 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.10.0
-Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio
-Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib
-Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing
-pipe -I/usr/local/include'
ccversion='', gccversion='4.3.2', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.8.90.so, so=so, useshrplib=true,
libperl=libperl.so.5.10.0
gnulibc_version='2.8.90'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'
Characteristics of this binary (from libperl
ModPerl + Perl 5.10
I read that mod_perl 2.0.4 works with Perl 5.10. Should I upgrade from 5.8.8. to 5.10? from perl 5.10 release notes I saw that The Perl interpreter itself is faster with a smaller memory footprint, and has several UTF-8 and threading improvements. etc. I need a stable Apache + mo_perl + perl combination. Is perl5.10 + mod_perl2.0.4. the right way to go? (are all perl modules working ok under 5.10 ?) Thanks
Re: ModPerl + Perl 5.10
On Sat 26 Jul 2008, Oleg Burlaca wrote: I need a stable Apache + mo_perl + perl combination. Is perl5.10 + mod_perl2.0.4. the right way to go? yes, with prefork mpm. (are all perl modules working ok under 5.10 ?) You can't expect someone to tell you even if all perl modules are working by their own (without apache+mod_perl). But generally mod_perl2 is quite stable. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession
On Mon, May 19, 2008 at 09:33:49PM +0300, Niko Tyni wrote: On Mon, May 19, 2008 at 11:12:08AM +0200, Louis-David Mitterrand wrote: Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a segfault when using MasonX::Request::WithApacheSession: [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal Segmentation fault (11) [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal Segmentation fault (11) [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal Segmentation fault (11) ## When commented out perl 5.10 works fine request_class = 'MasonX::Request::WithApacheSession', This looks very similar to http://bugs.debian.org/480480, Cc'd as [EMAIL PROTECTED] . I just sent a stack backtrace there, no idea yet if the fault is with perl or mod_perl2. Thanks for the pointer and fine investigative work on reducing the problem to a perl one-liner! Awaiting upstream now... Cheers,
segfault with perl 5.10 + MasonX::Request::WithApacheSession
[this message elicited no answers so far from mason-users, so maybe the modperl community might be of help, thanks] Hi, Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a segfault when using MasonX::Request::WithApacheSession: [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal Segmentation fault (11) [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal Segmentation fault (11) [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal Segmentation fault (11) etc... I marked the problematic handler.pl block with comments: my $ah = new HTML::Mason::ApacheHandler( autohandler_name='ah.mc', dhandler_name='dh.mc', comp_root='/var/www', data_dir='/tmp/mason', error_mode='output', args_method='mod_perl', ## When commented out perl 5.10 works fine request_class = 'MasonX::Request::WithApacheSession', session_class = 'Apache::Session::Postgres', session_data_source = 'dbi:Pg:dbname=sessions', session_user_name = '', session_password = '', session_use_cookie = 1, session_cookie_expires = undef, ## When commented out perl 5.10 works fine ); When using a vanilla request_class all is well, but then I have to roll my own %session object (which is not a huge problem). I upgraded to libmasonx-request-withapachesession-perl_0.31-1_all.deb with no difference. Does someone have an idea about that segfault? Thanks,
Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession
On Mon, May 19, 2008 at 5:12 AM, Louis-David Mitterrand ## When commented out perl 5.10 works fine request_class = 'MasonX::Request::WithApacheSession', session_class = 'Apache::Session::Postgres', session_data_source = 'dbi:Pg:dbname=sessions', session_user_name = '', session_password = '', session_use_cookie = 1, session_cookie_expires = undef, ## When commented out perl 5.10 works fine My guess would be that your Postgres driver has a problem. Try running some Pg queries from Mason. - Perrin
Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession
Louis-David Mitterrand wrote: [this message elicited no answers so far from mason-users, so maybe the modperl community might be of help, thanks] Hi, Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a segfault when using MasonX::Request::WithApacheSession: [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal Segmentation fault (11) [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal Segmentation fault (11) [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal Segmentation fault (11) Did you rebuild mod_perl and libapreq with perl 5.10? etc... I marked the problematic handler.pl block with comments: my $ah = new HTML::Mason::ApacheHandler( autohandler_name='ah.mc', dhandler_name='dh.mc', comp_root='/var/www', data_dir='/tmp/mason', error_mode='output', args_method='mod_perl', ## When commented out perl 5.10 works fine request_class = 'MasonX::Request::WithApacheSession', session_class = 'Apache::Session::Postgres', session_data_source = 'dbi:Pg:dbname=sessions', session_user_name = '', session_password = '', session_use_cookie = 1, session_cookie_expires = undef, ## When commented out perl 5.10 works fine ); When using a vanilla request_class all is well, but then I have to roll my own %session object (which is not a huge problem). I upgraded to libmasonx-request-withapachesession-perl_0.31-1_all.deb with no difference. Does someone have an idea about that segfault? Thanks, -- Red Hot Penguin Consulting LLC mod_perl/PostgreSQL consulting and implementation http://www.redhotpenguin.com/
Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession
On Mon, May 19, 2008 at 10:31:06AM -0400, Perrin Harkins wrote:
On Mon, May 19, 2008 at 5:12 AM, Louis-David Mitterrand
## When commented out perl 5.10 works fine
request_class =
'MasonX::Request::WithApacheSession',
session_class = 'Apache::Session::Postgres',
session_data_source = 'dbi:Pg:dbname=sessions',
session_user_name = '',
session_password = '',
session_use_cookie = 1,
session_cookie_expires = undef,
## When commented out perl 5.10 works fine
My guess would be that your Postgres driver has a problem. Try
running some Pg queries from Mason.
I thought about that too, but declaring in my handler.pl:
sub handler {
$HTML::Mason::Commands::dbc = DBI-connect(dbi:Pg:dbname=critik, ,
, {RaiseError=1, PrintError=1,
AutoCommit=1});
}
and using $dbc in my mason code works fine.
Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession
On Mon, May 19, 2008 at 07:32:18AM -0700, Fred Moyer wrote: Louis-David Mitterrand wrote: [this message elicited no answers so far from mason-users, so maybe the modperl community might be of help, thanks] Hi, Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a segfault when using MasonX::Request::WithApacheSession: [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal Segmentation fault (11) [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal Segmentation fault (11) [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal Segmentation fault (11) Did you rebuild mod_perl and libapreq with perl 5.10? I'm using debian packages which are rebuilt with perl 5.10: libapache2-request-perl 2.08-5+b1 Depends: perl (= 5.10.0-9) libapache2-mod-perl2 2.0.4-1 Depends: perl (= 5.10.0-9) and anyway mod_perl seems to work fine except when using request_class = 'MasonX::Request::WithApacheSession'
Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession
On Mon, May 19, 2008 at 11:12:08AM +0200, Louis-David Mitterrand wrote: Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a segfault when using MasonX::Request::WithApacheSession: [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal Segmentation fault (11) [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal Segmentation fault (11) [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal Segmentation fault (11) ## When commented out perl 5.10 works fine request_class = 'MasonX::Request::WithApacheSession', This looks very similar to http://bugs.debian.org/480480, Cc'd as [EMAIL PROTECTED] . I just sent a stack backtrace there, no idea yet if the fault is with perl or mod_perl2. Cheers, -- Niko Tyni [EMAIL PROTECTED]
Re: [mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc
On Mon, Mar 10, 2008 at 10:53:54PM -0700, Philippe M. Chiasson wrote: Niko Tyni wrote: We're switching to Perl 5.10 in Debian soon, and I'm trying to update the mod_perl2 package to keep it working. Unfortunately the ModPerl-Registry test suite is failing on the Sparc architecture because apache2 is killed by a bus error (SIGBUS). How about this s/U16/U32/ diff, basically keeping the flag type at U32, since it was not an essential part of the fix itself. No, that doesn't help either. It turns out the U16/U32 thing was a bad guess on my part. After some code staring and debugging, I found the real bug. It's not architecture-specific really, it just happens to bite worst on Sparc. The non-void function modperl_thx_interp_get() function is doing a plain 'return;' when it means to 'return NULL;'. The result is that the MP_APR_POOL_SV_TAKES_OWNERSHIP() macro increments a more or less random memory location, in this case my_perl-tScopestack aka. PL_scopestack, making it non-aligned as a side effect. Patch attached; this fixes the bus error for me. Cheers, -- Niko Tyni [EMAIL PROTECTED] Index: src/modules/perl/modperl_interp.c === --- src/modules/perl/modperl_interp.c (revision 635485) +++ src/modules/perl/modperl_interp.c (working copy) @@ -581,7 +581,7 @@ modperl_interp_t *interp; dTHXa(thx); SV **svp = hv_fetch(PL_modglobal, MP_THX_INTERP_KEY, strlen(MP_THX_INTERP_KEY), 0); -if (!svp) return; +if (!svp) return NULL; interp = INT2PTR(modperl_interp_t *, SvIV(*svp)); return interp; }
Re: [mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc
Niko Tyni wrote: On Mon, Mar 10, 2008 at 10:53:54PM -0700, Philippe M. Chiasson wrote: Niko Tyni wrote: We're switching to Perl 5.10 in Debian soon, and I'm trying to update the mod_perl2 package to keep it working. Unfortunately the ModPerl-Registry test suite is failing on the Sparc architecture because apache2 is killed by a bus error (SIGBUS). How about this s/U16/U32/ diff, basically keeping the flag type at U32, since it was not an essential part of the fix itself. No, that doesn't help either. It turns out the U16/U32 thing was a bad guess on my part. After some code staring and debugging, I found the real bug. It's not architecture-specific really, it just happens to bite worst on Sparc. Thanks a lot for the debugging work! Committed revision 636631. -- Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/ signature.asc Description: OpenPGP digital signature
Re: [mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc
Niko Tyni wrote:
[Resending, as my first try on March 1st apparently got lost somewhere.
Apologies if this ends up as a duplicate.]
1. Problem Description:
We're switching to Perl 5.10 in Debian soon, and I'm trying to update the
mod_perl2 package to keep it working. Unfortunately the ModPerl-Registry
test suite is failing on the Sparc architecture because apache2 is killed
by a bus error (SIGBUS).
I can reproduce this with a clean current SVN trunk (r631932)
without any Debian-specific changes, and bisecting shows it broke with
r620440. This is still with Perl 5.8.8 (from Debian unstable, package
version 5.8.8-12).
The kernel messages show the SIGBUS is an unaligned access (as usual on
Sparc). I assume the U32-U16 changes in r615751 are related.
Good old Sparc!
Does this patch make the problem go away? (untested)
Index: src/modules/perl/modperl_mgv.c
===
--- src/modules/perl/modperl_mgv.c (revision 635455)
+++ src/modules/perl/modperl_mgv.c (working copy)
@@ -271,7 +271,7 @@
}
else {
if ((cv = get_cv(name, FALSE))) {
-handler-attrs = *modperl_code_attrs(aTHX_ cv);
+memcpy((handler-attrs),modperl_code_attrs(aTHX_ cv),
sizeof(handler-attrs));
handler-mgv_cv =
modperl_mgv_compile(aTHX_ p, HvNAME(GvSTASH(CvGV(cv;
modperl_mgv_append(aTHX_ p, handler-mgv_cv, GvNAME(CvGV(cv)));
@@ -334,7 +334,7 @@
modperl_mgv_new_name(handler-mgv_obj, p, name);
}
-handler-attrs = *modperl_code_attrs(aTHX_ cv);
+memcpy((handler-attrs),modperl_code_attrs(aTHX_ cv),
sizeof(handler-attrs));
/* note: this is the real function after @ISA lookup */
handler-mgv_cv = modperl_mgv_compile(aTHX_ p, HvNAME(GvSTASH(gv)));
modperl_mgv_append(aTHX_ p, handler-mgv_cv, handler_name);
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
signature.asc
Description: OpenPGP digital signature
Re: [mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc
On Mon, Mar 10, 2008 at 12:06:54AM -0700, Philippe M. Chiasson wrote: Niko Tyni wrote: We're switching to Perl 5.10 in Debian soon, and I'm trying to update the mod_perl2 package to keep it working. Unfortunately the ModPerl-Registry test suite is failing on the Sparc architecture because apache2 is killed by a bus error (SIGBUS). Does this patch make the problem go away? (untested) -handler-attrs = *modperl_code_attrs(aTHX_ cv); +memcpy((handler-attrs),modperl_code_attrs(aTHX_ cv), sizeof(handler-attrs)); No, unfortunately I can't see any change at all with this patch. The backtrace looks just the same. -- Niko Tyni [EMAIL PROTECTED]
Re: mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail
Jie Gao wrote: Hi All Has this problem been solved finally in dev? No, not yet. The main problem getting looked at lately was Perl 5.10, and now that it looks like that is working. You should try building the svn trunk with the following patch applied and report if it fixes your problem: http://mid.gmane.org/[EMAIL PROTECTED] Regards, Jie On Tue, 25 Dec 2007, Heiko Jansen wrote: Date: Tue, 25 Dec 2007 19:59:14 +0100 From: Heiko Jansen [EMAIL PROTECTED] To: modperl@perl.apache.org Subject: mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail Hi *. I'm having trouble getting mod_perl to work with Perl 5.10 and Apache 2.2.6 on Solaris 64Bit/SPARC using Sun cc (Sun C 5.8 2005/10/13), compiling as 64Bit app. This applies to both mod_perl 2.0.3 and the latest (as of today) mod_perl/2.0.4-dev. 2.0.3 won't build at all unless I copy src/modules/perl/modperl_common_util.h and src/modules/perl/modperl_interp.h over from the dev tree. Then it compiles fine. Bad hack, of course. 2.0.4-dev compiles out of the box. However, running the tests, I see a bunch of errors in either case. I'm adding the test output and some info on my Perl. The error log will follow in a second mail due to the mail size limit for the list. If I should provide some more info or if there is anything I could test locally, please let me know. Thx. Heiko Taken from 2.0.4-dev: [...] APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /digibib/tools/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 [warning] Skipping 'set unlimited ulimit for coredumps', since we are running as a non-root user on Solaris /digibib/apache-2.2.6/bin/httpd -d /digibib/src/modperl-2.0/t -f /digibib/src/modperl-2.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.6 (worker MPM) [...] t/apache/add_config...ok [...These tests worked...] t/api/lookup_misc.ok t/api/lookup_uri..EXPECTED: pre+subreq=lookup_uri;filter=none+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=none at t/api/lookup_uri.t line 29. t/api/lookup_uri..1/4 # Failed test 1 in t/api/lookup_uri.t at line 30 EXPECTED: pre+pre+subreq=lookup_uri;filter=first+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=first at t/api/lookup_uri.t line 29. # Failed test 2 in t/api/lookup_uri.t at line 30 fail #2 EXPECTED: pre+subreq=lookup_uri;filter=second+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=second at t/api/lookup_uri.t line 29. # Failed test 3 in t/api/lookup_uri.t at line 30 fail #3 EXPECTED: pre+subreq=lookup_uri;filter=default+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=default at t/api/lookup_uri.t line 29. # Failed test 4 in t/api/lookup_uri.t at line 30 fail #4 [NOTE: the EXPECTED:/RECEIVED: warnings were added by me in .t file] t/api/lookup_uri.. Failed 4/4 subtests t/api/lookup_uri2.ok t/api/module..ok t/api/process.ok t/api/query...ok t/api/request_rec.ok t/api/request_subclassok t/api/request_utilok t/api/responseok t/api/rflush..1/2 # Failed test 1 in t/api/rflush.t at line 14 # Failed test 2 in t/api/rflush.t at line 20 t/api/rflush.. Failed 2/2 subtests t/api/sendfileok [...These tests worked...] t/filter/both_str_con_add.ok t/filter/both_str_native_remove...1/8 # Failed test 3 in t/filter/both_str_native_remove.t at line 33 # Failed test 6 in t/filter/both_str_native_remove.t at line 45 # Failed test 7 in t/filter/both_str_native_remove.t at line 49 # Failed test 8 in t/filter/both_str_native_remove.t at line 53 t/filter/both_str_native_remove... Failed 4/8 subtests t/filter/both_str_req_add.1/1 # Failed test 1 in t/filter/both_str_req_add.t at line 16 t/filter/both_str_req_add. Failed 1/1 subtests t/filter/both_str_req_mix.1/1 # Failed test 1 in t/filter/both_str_req_mix.t at line 33 t/filter/both_str_req_mix. Failed 1/1 subtests t/filter/both_str_req_proxy...1/1 # Failed test 1 in t/filter/both_str_req_proxy.t at line 16 t/filter/both_str_req_proxy... Failed 1/1 subtests t/filter/in_autoload..1/1 # Failed test 1 in t/filter/in_autoload.t at line 16 t/filter/in_autoload.. Failed 1/1 subtests t/filter/in_bbs_body.. Failed 2/3 subtests t/filter/in_bbs_consume...1/1 # Failed test 1 in t/filter/in_bbs_consume.t at line 19 t/filter/in_bbs_consume... Failed 1/1 subtests t/filter
Re: mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail
Hi All Has this problem been finally solved in dev? Regards, Jie On Tue, 25 Dec 2007, Heiko Jansen wrote: Date: Tue, 25 Dec 2007 19:59:14 +0100 From: Heiko Jansen [EMAIL PROTECTED] To: modperl@perl.apache.org Subject: mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail Hi *. I'm having trouble getting mod_perl to work with Perl 5.10 and Apache 2.2.6 on Solaris 64Bit/SPARC using Sun cc (Sun C 5.8 2005/10/13), compiling as 64Bit app. This applies to both mod_perl 2.0.3 and the latest (as of today) mod_perl/2.0.4-dev. 2.0.3 won't build at all unless I copy src/modules/perl/modperl_common_util.h and src/modules/perl/modperl_interp.h over from the dev tree. Then it compiles fine. Bad hack, of course. 2.0.4-dev compiles out of the box. However, running the tests, I see a bunch of errors in either case. I'm adding the test output and some info on my Perl. The error log will follow in a second mail due to the mail size limit for the list. If I should provide some more info or if there is anything I could test locally, please let me know. Thx. Heiko Taken from 2.0.4-dev: [...] APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /digibib/tools/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 [warning] Skipping 'set unlimited ulimit for coredumps', since we are running as a non-root user on Solaris /digibib/apache-2.2.6/bin/httpd -d /digibib/src/modperl-2.0/t -f /digibib/src/modperl-2.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.6 (worker MPM) [...] t/apache/add_config...ok [...These tests worked...] t/api/lookup_misc.ok t/api/lookup_uri..EXPECTED: pre+subreq=lookup_uri;filter=none+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=none at t/api/lookup_uri.t line 29. t/api/lookup_uri..1/4 # Failed test 1 in t/api/lookup_uri.t at line 30 EXPECTED: pre+pre+subreq=lookup_uri;filter=first+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=first at t/api/lookup_uri.t line 29. # Failed test 2 in t/api/lookup_uri.t at line 30 fail #2 EXPECTED: pre+subreq=lookup_uri;filter=second+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=second at t/api/lookup_uri.t line 29. # Failed test 3 in t/api/lookup_uri.t at line 30 fail #3 EXPECTED: pre+subreq=lookup_uri;filter=default+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=default at t/api/lookup_uri.t line 29. # Failed test 4 in t/api/lookup_uri.t at line 30 fail #4 [NOTE: the EXPECTED:/RECEIVED: warnings were added by me in .t file] t/api/lookup_uri.. Failed 4/4 subtests t/api/lookup_uri2.ok t/api/module..ok t/api/process.ok t/api/query...ok t/api/request_rec.ok t/api/request_subclassok t/api/request_utilok t/api/responseok t/api/rflush..1/2 # Failed test 1 in t/api/rflush.t at line 14 # Failed test 2 in t/api/rflush.t at line 20 t/api/rflush.. Failed 2/2 subtests t/api/sendfileok [...These tests worked...] t/filter/both_str_con_add.ok t/filter/both_str_native_remove...1/8 # Failed test 3 in t/filter/both_str_native_remove.t at line 33 # Failed test 6 in t/filter/both_str_native_remove.t at line 45 # Failed test 7 in t/filter/both_str_native_remove.t at line 49 # Failed test 8 in t/filter/both_str_native_remove.t at line 53 t/filter/both_str_native_remove... Failed 4/8 subtests t/filter/both_str_req_add.1/1 # Failed test 1 in t/filter/both_str_req_add.t at line 16 t/filter/both_str_req_add. Failed 1/1 subtests t/filter/both_str_req_mix.1/1 # Failed test 1 in t/filter/both_str_req_mix.t at line 33 t/filter/both_str_req_mix. Failed 1/1 subtests t/filter/both_str_req_proxy...1/1 # Failed test 1 in t/filter/both_str_req_proxy.t at line 16 t/filter/both_str_req_proxy... Failed 1/1 subtests t/filter/in_autoload..1/1 # Failed test 1 in t/filter/in_autoload.t at line 16 t/filter/in_autoload.. Failed 1/1 subtests t/filter/in_bbs_body.. Failed 2/3 subtests t/filter/in_bbs_consume...1/1 # Failed test 1 in t/filter/in_bbs_consume.t at line 19 t/filter/in_bbs_consume... Failed 1/1 subtests t/filter/in_bbs_inject_header.ok t/filter/in_bbs_msg...ok t/filter/in_bbs_underrun..ok t/filter/in_error.1/1 # Failed test 1 in t/filter/in_error.t at line 13 t/filter/in_error. Failed 1/1 subtests t/filter
Re: mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail
Hi All Has this problem been solved finally in dev? Regards, Jie On Tue, 25 Dec 2007, Heiko Jansen wrote: Date: Tue, 25 Dec 2007 19:59:14 +0100 From: Heiko Jansen [EMAIL PROTECTED] To: modperl@perl.apache.org Subject: mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail Hi *. I'm having trouble getting mod_perl to work with Perl 5.10 and Apache 2.2.6 on Solaris 64Bit/SPARC using Sun cc (Sun C 5.8 2005/10/13), compiling as 64Bit app. This applies to both mod_perl 2.0.3 and the latest (as of today) mod_perl/2.0.4-dev. 2.0.3 won't build at all unless I copy src/modules/perl/modperl_common_util.h and src/modules/perl/modperl_interp.h over from the dev tree. Then it compiles fine. Bad hack, of course. 2.0.4-dev compiles out of the box. However, running the tests, I see a bunch of errors in either case. I'm adding the test output and some info on my Perl. The error log will follow in a second mail due to the mail size limit for the list. If I should provide some more info or if there is anything I could test locally, please let me know. Thx. Heiko Taken from 2.0.4-dev: [...] APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /digibib/tools/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 [warning] Skipping 'set unlimited ulimit for coredumps', since we are running as a non-root user on Solaris /digibib/apache-2.2.6/bin/httpd -d /digibib/src/modperl-2.0/t -f /digibib/src/modperl-2.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.6 (worker MPM) [...] t/apache/add_config...ok [...These tests worked...] t/api/lookup_misc.ok t/api/lookup_uri..EXPECTED: pre+subreq=lookup_uri;filter=none+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=none at t/api/lookup_uri.t line 29. t/api/lookup_uri..1/4 # Failed test 1 in t/api/lookup_uri.t at line 30 EXPECTED: pre+pre+subreq=lookup_uri;filter=first+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=first at t/api/lookup_uri.t line 29. # Failed test 2 in t/api/lookup_uri.t at line 30 fail #2 EXPECTED: pre+subreq=lookup_uri;filter=second+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=second at t/api/lookup_uri.t line 29. # Failed test 3 in t/api/lookup_uri.t at line 30 fail #3 EXPECTED: pre+subreq=lookup_uri;filter=default+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=default at t/api/lookup_uri.t line 29. # Failed test 4 in t/api/lookup_uri.t at line 30 fail #4 [NOTE: the EXPECTED:/RECEIVED: warnings were added by me in .t file] t/api/lookup_uri.. Failed 4/4 subtests t/api/lookup_uri2.ok t/api/module..ok t/api/process.ok t/api/query...ok t/api/request_rec.ok t/api/request_subclassok t/api/request_utilok t/api/responseok t/api/rflush..1/2 # Failed test 1 in t/api/rflush.t at line 14 # Failed test 2 in t/api/rflush.t at line 20 t/api/rflush.. Failed 2/2 subtests t/api/sendfileok [...These tests worked...] t/filter/both_str_con_add.ok t/filter/both_str_native_remove...1/8 # Failed test 3 in t/filter/both_str_native_remove.t at line 33 # Failed test 6 in t/filter/both_str_native_remove.t at line 45 # Failed test 7 in t/filter/both_str_native_remove.t at line 49 # Failed test 8 in t/filter/both_str_native_remove.t at line 53 t/filter/both_str_native_remove... Failed 4/8 subtests t/filter/both_str_req_add.1/1 # Failed test 1 in t/filter/both_str_req_add.t at line 16 t/filter/both_str_req_add. Failed 1/1 subtests t/filter/both_str_req_mix.1/1 # Failed test 1 in t/filter/both_str_req_mix.t at line 33 t/filter/both_str_req_mix. Failed 1/1 subtests t/filter/both_str_req_proxy...1/1 # Failed test 1 in t/filter/both_str_req_proxy.t at line 16 t/filter/both_str_req_proxy... Failed 1/1 subtests t/filter/in_autoload..1/1 # Failed test 1 in t/filter/in_autoload.t at line 16 t/filter/in_autoload.. Failed 1/1 subtests t/filter/in_bbs_body.. Failed 2/3 subtests t/filter/in_bbs_consume...1/1 # Failed test 1 in t/filter/in_bbs_consume.t at line 19 t/filter/in_bbs_consume... Failed 1/1 subtests t/filter/in_bbs_inject_header.ok t/filter/in_bbs_msg...ok t/filter/in_bbs_underrun..ok t/filter/in_error.1/1 # Failed test 1 in t/filter
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
-0.5 I would actually like to see builds prepared against MSVCRT80, which is available in the Vista SDK's bundled free compiler, rather than having users need to download the SDK + VS Express Edition + configure the one to find and work with the other (a royal pain). As long as the latest SDKs are bundled with compilers (for x86, amd64 and even the ia64 for those who find that useful) there's no reason not to keep the build procedure as simple as possible for those of us *cough* who prefer not to buy a new VS suite every time MS feels like trying to send me one :-) My $0.02, Issac William A. Rowe, Jr. wrote: Well folks, here's the news... Studio 2008, true to form, proves that MS is incapable of keeping around a stdc library any longer than one product cycle. Yes, our long awaited (not) MSVCR90 is here. Just to put it in perspective, cross-library malloc/free, stdio and some other facilities are tightly integrated into the clib, such that compiling the application under one flavor, and using a library of another which modifies the application's memory/stdio allocations causes no end of troubles. You might be also curious if AS is making progress at coming to a new baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71 for python. Unfortunately, this version is also built under msvcrt. The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. So I'm posting this mostly for feedback to the rational of moving to a compiler that will generate reliable 32 *and* 64 bit builds of httpd, will be freely available (the point of the ASF is the source, and that users can do something with it), and that decision will be locked at the 2.4 release based on our strong commitment to binary compatibility. It's very true that modules compiled for another runtime can coexist very happily when the module does not free allocations from another component, don't attempt to share faux-posix stdio resources, etc. mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it lives very happily in a VC6 build of httpd. But the way that perl, mod_perl and httpd interact is not that trivial, and highly prone to this class of problems. So I figure if there's a plan here, it will likely satisfy the 80/20. If AS Perl can't part of that solution, so be it. Bill
Visual Studio 2008 and ActiveState Perl 5.10 updates
Well folks, here's the news... Studio 2008, true to form, proves that MS is incapable of keeping around a stdc library any longer than one product cycle. Yes, our long awaited (not) MSVCR90 is here. Just to put it in perspective, cross-library malloc/free, stdio and some other facilities are tightly integrated into the clib, such that compiling the application under one flavor, and using a library of another which modifies the application's memory/stdio allocations causes no end of troubles. You might be also curious if AS is making progress at coming to a new baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71 for python. Unfortunately, this version is also built under msvcrt. The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. So I'm posting this mostly for feedback to the rational of moving to a compiler that will generate reliable 32 *and* 64 bit builds of httpd, will be freely available (the point of the ASF is the source, and that users can do something with it), and that decision will be locked at the 2.4 release based on our strong commitment to binary compatibility. It's very true that modules compiled for another runtime can coexist very happily when the module does not free allocations from another component, don't attempt to share faux-posix stdio resources, etc. mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it lives very happily in a VC6 build of httpd. But the way that perl, mod_perl and httpd interact is not that trivial, and highly prone to this class of problems. So I figure if there's a plan here, it will likely satisfy the 80/20. If AS Perl can't part of that solution, so be it. Bill
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: Studio 2008, true to form, proves that MS is incapable of keeping around a stdc library any longer than one product cycle. Yes, our long awaited (not) MSVCR90 is here. You can expect a new runtime library version for each compiler release from Microsoft. This started back with VS.NET (MSVCR70), VS2003 (MSVCR71), VS2005 (MSVCR80) and now VS2008 (MSVCR90). The initial switch away from MSVCRT.dll was due to a conflict inside Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become so important to the operation of Windows itself that the compiler team was no longer allowed to update it; ownership had been transferred to the OS team and the only update vehicle was Windows Update. This made it impossible to include updated versions of MSVCRT.dll with Visual Studio releases, and the compiler team went back to versioned runtime libraries. Just to put it in perspective, cross-library malloc/free, stdio and some other facilities are tightly integrated into the clib, such that compiling the application under one flavor, and using a library of another which modifies the application's memory/stdio allocations causes no end of troubles. This is not really true for Perl, which abstracts all runtime library dependencies away. As long as you include the Perl headers in your module code, you will use the same runtime library as Perl itself. You might be also curious if AS is making progress at coming to a new baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71 for python. Unfortunately, this version is also built under msvcrt. This was a conscious decision: Using MSVCRT.dll as the runtime library has many advantages: the library is already installed on *all* Windows systems, so you never need to distribute it yourself. This is important for tools like PAR, PerlApp and Perl2Exe that create selfcontained executables of Perl applications. Using MSVCRT.dll also allows to use both VC++6 and GCC from MinGW without loading duplicate runtimes. I still haven't seen a compelling argument why someone wants to move away from using MSVCRT.dll (and then continue switching CRTs then every other year). The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. I tried back in the VS.NET days to compile with VC7 and link against MSVCRT.dll. It turned out to fail in some cases when compiler generated code (under C++) called help functions not present in MSVCRT.dll. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Why? What problems are going to happen? Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. This is not correct. All the 64-bit support code is already in Perl 5.8.x as well. So I'm posting this mostly for feedback to the rational of moving to a compiler that will generate reliable 32 *and* 64 bit builds of httpd, will be freely available (the point of the ASF is the source, and that users can do something with it), and that decision will be locked at the 2.4 release based on our strong commitment to binary compatibility. It's very true that modules compiled for another runtime can coexist very happily when the module does not free allocations from another component, don't attempt to share faux-posix stdio resources, etc. mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it lives very happily in a VC6 build of httpd. But the way that perl, mod_perl and httpd interact is not that trivial, and highly prone to this class of problems. So I figure if there's a plan here, it will likely satisfy the 80/20. If AS Perl can't part of that solution, so be it. I have no idea what you are trying to get at here, and where your fatalistic attitude comes from. If there is a real problem using ActivePerl with mod_perl, then please let me know about it. I'm sure we can work it out. :) Cheers, -Jan
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Jan Dubois wrote: The initial switch away from MSVCRT.dll was due to a conflict inside Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become so important to the operation of Windows itself that the compiler team was no longer allowed to update it; ownership had been transferred to the OS team and the only update vehicle was Windows Update. This made it impossible to include updated versions of MSVCRT.dll with Visual Studio releases, and the compiler team went back to versioned runtime libraries. A very interesting perspective, thanks! I still haven't seen a compelling argument why someone wants to move away from using MSVCRT.dll (and then continue switching CRTs then every other year). The obvious question is; what are your include libraries for that module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to build with VC 6? I'm concerned about drift; I understand the advantages to msvcrt.dll, but fail to see where the proper headers are derived from, and agree with some other posters that the performance advantage to moving to a more modern compiler will outweigh the desire to remain windows 9x compatible. One aspect of my current vc perspective is that really NT 4.0 and 9x are now dead, as in harmful when installed in the network cloud. So with the loss of further security fixes to the NT4/9x class OS's, I'm moving away from their support whatsoever for httpd 2.4 (3.0?) binaries. The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. I tried back in the VS.NET days to compile with VC7 and link against MSVCRT.dll. It turned out to fail in some cases when compiler generated code (under C++) called help functions not present in MSVCRT.dll. I'd expect that... but I'm more concerned about insidious failures which aren't clean compile/link time exceptions. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Why? What problems are going to happen? The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. This is not correct. All the 64-bit support code is already in Perl 5.8.x as well. Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our favorite perlmongers to put their full attention to 5.10 first (good choice IMHO). I have no idea what you are trying to get at here, and where your fatalistic attitude comes from. If there is a real problem using ActivePerl with mod_perl, then please let me know about it. I'm sure we can work it out. :) Certainly some folks who are actively using it already will chime in, I'm looking forward to their specific examples - it's why I brought this up on modperl's list. I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of any new box I personally use until and if I get around to building perl and python myself), but point out that the glue in malloc/free, faux-posix entities etc that have to span httpd to apr to modperl to perl do have issues today that have been reported on-list. I suspect a good number of these will, ultimately, be resolved with a consistent clib across all components. Alternate solution is for each component to manage it's own resources and abstract them for the consumer; we are getting there, slowly. The breadth of cpan packages doesn't make this easier ;-) For example, OpenSSL needs to be built for both a host of perl ssl packages and for httpd mod_ssl (and apr-util, in the near future). Which build? One compiled on VC 9 or VC 6? Bill
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: Jan Dubois wrote: I still haven't seen a compelling argument why someone wants to move away from using MSVCRT.dll (and then continue switching CRTs then every other year). The obvious question is; what are your include libraries for that module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to build with VC 6? That Platform SDK headers (in case the module uses APIs that were introduced with Win2K or later), followed by the VC6 ones for traditional CRT stuff. I'm concerned about drift; I understand the advantages to msvcrt.dll, but fail to see where the proper headers are derived from, and agree with some other posters that the performance advantage to moving to a more modern compiler will outweigh the desire to remain windows 9x compatible. I don't see how Windows 9X/NT compatibility plays a role here. E.g. for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is Windows 2000, but the code is still using MSVCRT.dll for the various reasons I listed. That being said, we don't go out of our way to *break* Win9X compatibility, but we don't test on it, and won't try to fix anything unless it is obvious/trivial. I'm interested in the potential performance advantage though. Did you do any measurements? I've only heard anecdotal evidence of a 5% improvement that leaves me quite unimpressed (for things like PerlBench a 5% difference is almost at the noise level). My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Why? What problems are going to happen? The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Sure, but how do resources cross? Isn't this always a module bug to start with? Note that I have virtually no experience with the particular issues you may see with Perl inside Apache, but I've worked on many Perl embedding scenarios, putting Perl into COM controls, Windows services and .NET applications, so I'm well aware of the general issues, and how to solve them/work around them. Therefore I'm genuinely interested to learn where the problems are if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl with VC7. I would expect this to work just fine if we ignore the address space wasted by essentially unused surplus clibs. This is not correct. All the 64-bit support code is already in Perl 5.8.x as well. Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our favorite perlmongers to put their full attention to 5.10 first (good choice IMHO). It used to work in earlier Perl 5.8.x versions too, but later releases of the 64-bit VC compiler in the Platform SDK broke things. I thought I fixed this ages ago, but I guess I only submitted the necessary patches earlier this year and they had not been included in any official P5P release: http://public.activestate.com/cgi-bin/perlbrowse/p/30878 However, there have been 64-bit ActivePerl releases of 5.8.8 on Windows since August 2006. Just FYI, all the 64-bit ActivePerl on Windows releases have been built with the VC version from the Windows Server 2003 SP1 SDK. That compiler is a special version of the VS2003 compiler that links against the 64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in a special bufferoverflowU.lib library if you use the /GS compiler option because MSVCRT.dll doesn't include the runtime support for the buffer overrun detection. Certainly some folks who are actively using it already will chime in, I'm looking forward to their specific examples - it's why I brought this up on modperl's list. Yes, please speak up; I'm very interested to hear about it. I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of any new box I personally use until and if I get around to building perl and python myself), but point out that the glue in malloc/free, faux-posix entities etc that have to span httpd to apr to modperl to perl do have issues today that have been reported on-list. I may have missed these, as I only skim the mod_perl mailing lists. I always assumes that you would either use the Newx()/Safefree() mechanism from Perl, or a corresponding mechanism from APR to manage your memory. Mixing them can be dangerous even with a single clib because the Perl mechanism may use memory before and after the allocated block to detect buffer overruns in testing builds etc. I suspect a good number of
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, Jan Dubois wrote: On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: [ ... ] My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Why? What problems are going to happen? The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Sure, but how do resources cross? Isn't this always a module bug to start with? Note that I have virtually no experience with the particular issues you may see with Perl inside Apache, but I've worked on many Perl embedding scenarios, putting Perl into COM controls, Windows services and .NET applications, so I'm well aware of the general issues, and how to solve them/work around them. Therefore I'm genuinely interested to learn where the problems are if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl with VC7. I would expect this to work just fine if we ignore the address space wasted by essentially unused surplus clibs. I'm not sure if this is a clean example, but there was a report: http://marc.info/?l=apache-modperlm=119140365320503w=2 where mod_perl and Apache (compiled with VC8) did not work with ActivePerl (VC6), whereas switching to a mod_perl compiled with VC6 with the same Apache and Perl did (seemingly) work. Also, Steve Hay reports that his Win32::SharedFileOpen module: http://search.cpan.org/src/SHAY/Win32-SharedFileOpen-3.36/INSTALL and his Win32::UTCFileTime module: http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL will only work with ActivePerl when they're compiled with VC6. -- best regards, Randy
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Jan Dubois wrote: On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: The obvious question is; what are your include libraries for that module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to build with VC 6? That Platform SDK headers (in case the module uses APIs that were introduced with Win2K or later), followed by the VC6 ones for traditional CRT stuff. Bingo! Ok, so we are clear, we are still building to VC6. I just wanted to clarify that this isn't mixing and matching to MSVCRxx headers from a later compiler. In theory that might even be possible, but it's only fair to point out that it's becoming impossible to download VC6 or obtain the SDK flavor which will actually compile under it. Or are you compiling with a more modern VC against the older VC6 headers? (The issue with obtaining them remains). I don't see how Windows 9X/NT compatibility plays a role here. E.g. for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is Windows 2000, but the code is still using MSVCRT.dll for the various reasons I listed. Right - understood. That being said, we don't go out of our way to *break* Win9X compatibility, but we don't test on it, and won't try to fix anything unless it is obvious/trivial. :) Ditto, although I'm less vigorous about providing dynaload thunks now, unless a 2008/Vista or 2003/XP API would break on 2000. I'm interested in the potential performance advantage though. Did you do any measurements? I've only heard anecdotal evidence of a 5% improvement that leaves me quite unimpressed (for things like PerlBench a 5% difference is almost at the noise level). Right; we have entirely different designs on performance. For httpd, 5% would be a godsend :) I'll be collecting and reporting on such in the near future. The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Sure, but how do resources cross? Isn't this always a module bug to start with? Note that I have virtually no experience with the particular issues you may see with Perl inside Apache, but I've worked on many Perl embedding scenarios, putting Perl into COM controls, Windows services and .NET applications, so I'm well aware of the general issues, and how to solve them/work around them. Yup - it's almost always the same story; some API returns memory that it expects the caller to free(), rather than a corresponding API release call. There are a host of such examples in the way that mod_perl was implemented. Even some of the API's (as I hint about the SSL modules) which are implemented as xs's that behave similarly. Therefore I'm genuinely interested to learn where the problems are if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl with VC7. I would expect this to work just fine if we ignore the address space wasted by essentially unused surplus clibs. Right; we aren't talking about optimizing, but simply interop. It used to work in earlier Perl 5.8.x versions too, but later releases of the 64-bit VC compiler in the Platform SDK broke things. I thought I fixed this ages ago, but I guess I only submitted the necessary patches earlier this year and they had not been included in any official P5P release: http://public.activestate.com/cgi-bin/perlbrowse/p/30878 However, there have been 64-bit ActivePerl releases of 5.8.8 on Windows since August 2006. :) Just FYI, all the 64-bit ActivePerl on Windows releases have been built with the VC version from the Windows Server 2003 SP1 SDK. That compiler is a special version of the VS2003 compiler that links against the 64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in a special bufferoverflowU.lib library if you use the /GS compiler option because MSVCRT.dll doesn't include the runtime support for the buffer overrun detection. Interesting detail, thanks. I had presumed as much (or that you had built it against an earlier DDK before they incorporated this fully into the SDK). I may have missed these, as I only skim the mod_perl mailing lists. I always assumes that you would either use the Newx()/Safefree() mechanism from Perl, or a corresponding mechanism from APR to manage your memory. Mixing them can be dangerous even with a single clib because the Perl mechanism may use memory before and after the allocated block to detect buffer overruns in testing builds etc. Right - of course should-be and are-actually are two different things :) And it's only fair to point out this isn't win32 specific, libs linked against an optimized allocator on various flavors of unix will blow up in similar ways when the consuming app is linked to the 'stock' allocator. I sure hope that the problems can be solved by proper encapsulation of the different components. Re-releasing all components in sync whenever Microsoft releases a new compiler sounds
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, Randy Kobes wrote: On Fri, 28 Dec 2007, Jan Dubois wrote: Therefore I'm genuinely interested to learn where the problems are if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl with VC7. I would expect this to work just fine if we ignore the address space wasted by essentially unused surplus clibs. I'm not sure if this is a clean example, but there was a report: http://marc.info/?l=apache-modperlm=119140365320503w=2 where mod_perl and Apache (compiled with VC8) did not work with ActivePerl (VC6), whereas switching to a mod_perl compiled with VC6 with the same Apache and Perl did (seemingly) work. I didn't find enough information in that thread to figure out what the problem might be. It could very well be a module issue and not a problem with mod_perl itself. Also, Steve Hay reports that his Win32::SharedFileOpen module: http://search.cpan.org/src/SHAY/Win32-SharedFileOpen-3.36/INSTALL and his Win32::UTCFileTime module: http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL will only work with ActivePerl when they're compiled with VC6. I've looked at both, and they indeed must be compiled using the same runtime library as the corresponding perl5x.dll: Both modules use core Perl APIs and either insert FILE* pointers received from the CRT into Perl data structures, or try to turn a FILE* pointer from Perl into a fileno using the CRT. Both extensions contain code that should ideally be part of the core. Or at least the core should provide the necessary thunks to access the corresponding functions from its own CRT. I wonder if there are many modules though that do this kind of diddling with the PerlIO subsystem internals. If there aren't, then I can see a few ways to resolve this: * Maybe the functionality of these modules should be supported by the core. I believe Steve already asked if the Win32::UTCFileTime code shouldn't be the default for Perl's handling of filetimes. * Maybe we should add the required thunks to Perl. E.g. add a Perl_get_osfhandle() function etc. * Maybe add the modules to ActivePerl and/or the PPM repositories. (They should already be on the PPM server, but seem to be missing due to some buildbox meltdown). Cheers, -Jan
mod_perl, Perl 5.10, Apache 2.2.6 = Tests fail
Hi *. I'm having trouble getting mod_perl to work with Perl 5.10 and Apache 2.2.6 on Solaris 64Bit/SPARC using Sun cc (Sun C 5.8 2005/10/13), compiling as 64Bit app. This applies to both mod_perl 2.0.3 and the latest (as of today) mod_perl/2.0.4-dev. 2.0.3 won't build at all unless I copy src/modules/perl/modperl_common_util.h and src/modules/perl/modperl_interp.h over from the dev tree. Then it compiles fine. Bad hack, of course. 2.0.4-dev compiles out of the box. However, running the tests, I see a bunch of errors in either case. I'm adding the test output and some info on my Perl. The error log will follow in a second mail due to the mail size limit for the list. If I should provide some more info or if there is anything I could test locally, please let me know. Thx. Heiko Taken from 2.0.4-dev: [...] APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /digibib/tools/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 [warning] Skipping 'set unlimited ulimit for coredumps', since we are running as a non-root user on Solaris /digibib/apache-2.2.6/bin/httpd -d /digibib/src/modperl-2.0/t -f /digibib/src/modperl-2.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.6 (worker MPM) [...] t/apache/add_config...ok [...These tests worked...] t/api/lookup_misc.ok t/api/lookup_uri..EXPECTED: pre+subreq=lookup_uri;filter=none+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=none at t/api/lookup_uri.t line 29. t/api/lookup_uri..1/4 # Failed test 1 in t/api/lookup_uri.t at line 30 EXPECTED: pre+pre+subreq=lookup_uri;filter=first+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=first at t/api/lookup_uri.t line 29. # Failed test 2 in t/api/lookup_uri.t at line 30 fail #2 EXPECTED: pre+subreq=lookup_uri;filter=second+suf+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=second at t/api/lookup_uri.t line 29. # Failed test 3 in t/api/lookup_uri.t at line 30 fail #3 EXPECTED: pre+subreq=lookup_uri;filter=default+suf at t/api/lookup_uri.t line 28. RECEIVED: subreq=lookup_uri;filter=default at t/api/lookup_uri.t line 29. # Failed test 4 in t/api/lookup_uri.t at line 30 fail #4 [NOTE: the EXPECTED:/RECEIVED: warnings were added by me in .t file] t/api/lookup_uri.. Failed 4/4 subtests t/api/lookup_uri2.ok t/api/module..ok t/api/process.ok t/api/query...ok t/api/request_rec.ok t/api/request_subclassok t/api/request_utilok t/api/responseok t/api/rflush..1/2 # Failed test 1 in t/api/rflush.t at line 14 # Failed test 2 in t/api/rflush.t at line 20 t/api/rflush.. Failed 2/2 subtests t/api/sendfileok [...These tests worked...] t/filter/both_str_con_add.ok t/filter/both_str_native_remove...1/8 # Failed test 3 in t/filter/both_str_native_remove.t at line 33 # Failed test 6 in t/filter/both_str_native_remove.t at line 45 # Failed test 7 in t/filter/both_str_native_remove.t at line 49 # Failed test 8 in t/filter/both_str_native_remove.t at line 53 t/filter/both_str_native_remove... Failed 4/8 subtests t/filter/both_str_req_add.1/1 # Failed test 1 in t/filter/both_str_req_add.t at line 16 t/filter/both_str_req_add. Failed 1/1 subtests t/filter/both_str_req_mix.1/1 # Failed test 1 in t/filter/both_str_req_mix.t at line 33 t/filter/both_str_req_mix. Failed 1/1 subtests t/filter/both_str_req_proxy...1/1 # Failed test 1 in t/filter/both_str_req_proxy.t at line 16 t/filter/both_str_req_proxy... Failed 1/1 subtests t/filter/in_autoload..1/1 # Failed test 1 in t/filter/in_autoload.t at line 16 t/filter/in_autoload.. Failed 1/1 subtests t/filter/in_bbs_body.. Failed 2/3 subtests t/filter/in_bbs_consume...1/1 # Failed test 1 in t/filter/in_bbs_consume.t at line 19 t/filter/in_bbs_consume... Failed 1/1 subtests t/filter/in_bbs_inject_header.ok t/filter/in_bbs_msg...ok t/filter/in_bbs_underrun..ok t/filter/in_error.1/1 # Failed test 1 in t/filter/in_error.t at line 13 t/filter/in_error. Failed 1/1 subtests t/filter/in_init_basic1/1 # Failed test 1 in t/filter/in_init_basic.t at line 16 t/filter/in_init_basic Failed 1/1 subtests t/filter/in_str_bin_data..ok t/filter/in_str_consume...1/1 # Failed test 1 in t/filter
Re: Perl 5.10
On 12/21/07 2:32 AM, Andreas J. Koenig wrote: I fear I do not understand enough of mod_perl to volunteer to make a release. Me neither, but have you at least contacted the mod_perl maintainers about this? Perhaps you could file a bug on rt.cpan.org even? -John
Re: Perl 5.10
John Siracusa wrote: On 12/21/07 2:32 AM, Andreas J. Koenig wrote: I fear I do not understand enough of mod_perl to volunteer to make a release. Me neither, but have you at least contacted the mod_perl maintainers about this? Perhaps you could file a bug on rt.cpan.org even? the current maintainers hang out here :) we'll try to roll a mp1 release soonish, which should address 5.10 issues. with the holidays it might be difficult, but hopefully it won't take too long after the new year. --Geoff
Re: Perl 5.10
Andreas J. Koenig wrote: Modperl1 doesn't work, patch available. As for modperl2 I don't know. I've been running 5.10 in my modperl2/apache2.2 sandbox development environment since yesterday. Haven't run into any issues related to 5.10 yet, but its still early on for me :). Regards, Michael Schout
Re: Perl 5.10
Andreas J. Koenig wrote: On Thu, 20 Dec 2007 11:38:02 -0500, Colin Wetherbee [EMAIL PROTECTED] said: Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? Modperl1 doesn't work, patch available. As for modperl2 I don't know. I apparently should not have sent the last email. I have since found a problem for me. I'm having trouble getting my custom PerlOutputFilterHandler to fire. It works flawlessly under the same mod_perl 2.0.3/apache 2.2.6/perl 5.8.8.. but with 5.10, *usually* it refuses to run it and just says: [Fri Dec 21 10:57:47 2007] [error] an unknown filter was not added: Foo::Filter::StripWhiteSpace I thought it might be Attribute::Handlers related since ::StripWhiteSpace-handler is defined with the :method attr. But changing the config to specify the method name as well does not help either. I haven't had time to figure out what is going on yet. It could be something specific to my setup ;). Regards, Michael Schout
Re: Perl 5.10
Michael Schout wrote: [Fri Dec 21 10:57:47 2007] [error] an unknown filter was not added: Foo::Filter::StripWhiteSpace in addition, with PerlTrace enabled, I get: modperl_filter_add_request: a non-mod_perl OutputFilter handler Foo::Filter::StripWhiteSpace configured. Regards, Michael Schout
Re: Perl 5.10
Colin Wetherbee wrote: Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? Apparently so. I have found the cause of my sometimes-it-works sometimes-it-doesnt problem for PerlOutputFilterHandlers. I tracked the problem down to MP_CODE_ATTRS(), called from modperl_mgv.c on line 276: handler-attrs = (U32)MP_CODE_ATTRS(cv); I added some MP_TRACE()'s around this line and found out that MP_CODE_ATTRS(cv) returns some random looking data under 5.10. Looking at mod_perl.h, it says: /* betting on Perl*Handlers not using CvXSUBANY * mod_perl reuses this field for handler attributes */ #define MP_CODE_ATTRS(cv) (CvXSUBANY((CV*)cv).any_i32) This must not be a safe bet under perl 5.10.0. I have no idea what to do as an alternative. I don't know enough perl internals :). Here is what the MP_TRACE()'s before and after he MP_CODE_ATTRS() call looks like under 5.8.8: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 0 Under 5.10.0 its a much different story: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 9905fb8 The sometimes-it-works sometimes-it-doesnt behaviour depends on if the right bits end up getting set in the attrs from the random data coming out of MP_CODE_ATTRS(). Oh well, I'm going back to 5.8.8 for now I guess :). I'll file a bug report as well :). Regards, Michael Schout
Perl 5.10
Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? I'm still waiting on the release of the Debian packages. Colin
Re: Perl 5.10
On Thu, 20 Dec 2007 11:38:02 -0500, Colin Wetherbee [EMAIL PROTECTED] said: Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? Modperl1 doesn't work, patch available. As for modperl2 I don't know. I'm resending my posting which probably got lost in a moderator queue or what (I just re-subscribed, so this one should probasbly come through): From: [EMAIL PROTECTED] (Andreas J. Koenig) Subject: perl 5.10 will not work with modperl 1.30, please consider new release To: modperl@perl.apache.org Date: Fri, 14 Dec 2007 08:28:14 +0100 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00278.html This is the currently latest posting in the thread that worked out the relevant issue. Would be really cool if mod_perl1 could be brought up to date so that people working with 5.10 do not have to hunt for patches. I fear I do not understand enough of mod_perl to volunteer to make a release. Thanks, -- andreas
