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/in_str
Re: compiling problems with mod_perl 2.0.3 and Apache 2.2.6
Am Freitag, den 18.01.2008, 15:47 +1030 schrieb James Breat: > I am having problems a static mod_perl with Apache 2.2.6 and > Perl 5.10.0. Essentially, the answer you need is: Don't use mod_perl2 and Perl 5.10.0 together yet. As far as I know, the mod_perl developers are working on resolving the issues (caused by internal changes in Perl 5.10) right now. So we both have to wait for mod_perl 2.0.4... heiko
Re: Apache::DProf giving empty tmon.out files
Am Montag, den 21.01.2008, 06:19 -0800 schrieb Alx G: > No worries. For the record, I just tried putting the DB->init before > everything else (after loading mod_perl obviously) in the conf - no joy > though. The Apache::DB POD mentions using "use APR::Pool ();" right before "use Apache::DB ();" But I don't think that's the point, since there is at least some output in the files. > The code I'm running is just a collection of cgi scripts that hook > into the back-end libraries of the system, so the code is definitely loaded > and run after the the DB->init and Dprof module. But surely they're not run as plain old cgi? Sorry, just had to ask - sometimes I found out that it was the most obvious thing that I somehow forgot about... Heiko
Re: Apache::DProf giving empty tmon.out files
>>> Alx G <[EMAIL PROTECTED]> 21.01.08 17.25 Uhr >>>
> If I output the value of
> $ENV{'mod_perl'} it shows mod_perl/2.0.2 (or something like that), so
I
> believe that shows it's not running as plain cgi.
Yep, looks good.
I've no experience with Apache::DB - so apart from one last
excerpt from the docs that I've seen I've nothing more to offer:
I believe you should have sth. like this in your Apache conf for the
location you serve your scripts from:
PerlFixupHandler Apache::DB
SetHandler perl-script
PerlHandler ModPerl::RegistryPrefork
Options +ExecCGI
If I'm wrong I hope someone will correct me...
All the best
heiko
Re: compiling problems with mod_perl 2.0.3 and Apache 2.2.6
Am Montag, den 21.01.2008, 23:12 -0800 schrieb Philippe M. Chiasson: > Yes, but mod_perl 2.0.3 and Perl 5.10 should at least _build_, just > possibly exhibit unnatural behaviour at runtime... No - at least not for me (Solaris 10, 64Bit, Sun cc): 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. Sadly I don't remember _why_ I had to copy these headers.. Bad hack, of course. Heiko
Re: proxy question
Am Donnerstag, den 31.01.2008, 11:31 + schrieb Martin Moss: > does mod_proxy provide more than round robin load balancing > functionlity? I'd been told it could, but I can't find anything in the > docs.. Actually this is not the right place to ask about other httpd modules than mod_perl, but still: Please have a look at http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html Heiko
Re: libperl.so Missing
Did you really build a shared library? ./Configure should have asked you if you want to build a static perl or a shared object/library Heiko Am Mittwoch, den 26.03.2008, 12:06 -0500 schrieb [EMAIL PROTECTED]: > Hello Folks, > > I have searched and re-installed stuff and cannot find the answer. > > libperl.so is nowhere to be foud. I have perl5.8.8 installed from sources on > Redhat > ES WS 4.1. Mod_perl2 and others are installed. I did mod_perl2 from sources > and > others from CPAN. > > Help would be MUCH appreciated! > > Thanks, > Robert A. Ober
Re: libperl.so Missing
Am Mittwoch, den 26.03.2008, 12:17 -0500 schrieb [EMAIL PROTECTED]: > On 26/Mar/2008 12:12 Heiko Jansen wrote .. > > Did you really build a shared library? > > > > ./Configure should have asked you if you want to build a static perl or > > a shared object/library > > > I have not had anything ask me that in years, but that is a good point. > No, it did not ask me. Huh?! As far as I remember I was asked that question every time I build a new perl (and that's been quite a few). The only reason (I can think of) to not ask you would be that ./Configure believes that your platform does not support it. I just re-executed the ./Configure of perl 5.8.8 to make sure and there it was: -- snip -- The perl executable is normally obtained by linking perlmain.c with libperl.a, any static extensions (usually just DynaLoader), and any other libraries needed on this system (such as -lm, etc.). Since your system supports dynamic loading, it is probably possible to build a shared libperl.so. If you will have more than one executable linked to libperl.so, this will significantly reduce the size of each executable, but it may have a noticeable effect on performance. The default is probably sensible for your system. Build a shared libperl.so (y/n) [n] -- / snip -- > Should I recompile with a switch? If so, what? None needed heiko Besuchen Sie das hbz auf der InetBib-Tagung vom 9. bis 11. April an Stand A1!
Re: Running Perl::Critic on Web App?
Am Donnerstag, den 27.03.2008, 06:30 -0700 schrieb amiribarksdale: > I am trying to tighten up the code in a web application I have made--I run > HTML::Mason and mod_perl--and I was trying to figure out how to run > Perl::Critic or some other diagnostic tool on the whole thing, so that it > would be active for every request and I could see problems throughout the > whole thing. I tried putting it in my main handler, but it only works on the > handler. I could put a use Perl::Critic on every Mason component, but that's > tedious. Is there a way to run a module on every request at the mod_perl > level? As the Perl::Critic POD tells you, it essentially a static source code analysis engine. As such it doesn't make sense to use it they way you describe. If you are interested how you code performs, you could have a look at http://search.cpan.org/~fwiles/Apache-DB-0.13/lib/Apache/DProf.pm or http://search.cpan.org/~timb/DashProfiler-1.12/ hth heiko
Re: Net-SSLeay-1.32 Confusion
Am Freitag, den 28.03.2008, 12:23 -0500 schrieb [EMAIL PROTECTED]: > Hello Folks, > > OpenCA tells me I need IO:Socket::SSL which apparently needs > Net::SSLeay. Installing Net::SSLeay from the interactive CPAN > utility fails. So I downloaded Net-SSLeay-1.32. At the top of the > README for Net-SSLeay-.32 is the following: > > README - Net::SSLeay Perl module for using OpenSSL > > Later the reaadme says: > > Note: SSLeay is no longer supported. If you want to use Net::SSLeay with > SSLeay or early versions of OpenSSL, use version 1.03. The support > for SSLeay was dropped due to nobody maintaining it (all active > work goes on with OpenSSL) and due to incompatible API changes > in OpenSSL-0.9.2b. OpenSSL-0.9.1c support has also been dropped, > version 1.03 was the last one to support that. > > Huh? If SSLeay is not supported then what is Net-SSLeay-1.32 for? Well, the above tells you that Net::SSL no longer works with SSLeay or with ancient versions of OpenSSL but requires OpenSSL post 0.9.2b to be present on your system. > What do I neeed to get IO::Socket:SSL to install? According to it's POD I'd say you need Net::SSLeay which in turn needs a more recent version of OpenSSL ;-) Now the interesting question is why the Net::SSLeay installation did not work. But we can't answer that without more info - but also this is a topic beyond the scope of this list... heiko
Re: mod_perl V 2.0.4 and undefined symbol: boot_DynaLoader
Am Montag, den 19.05.2008, 19:34 +1000 schrieb Ron Savage:
> of /home/ron/httpd/prefork/conf/httpd.conf: Cannot
> load /home/ron/httpd/prefork/modules/mod_perl.so into
> server: /home/ron/httpd/prefork/modules/mod_perl.so: undefined symbol:
> boot_DynaLoader
> <===8><===>
>
> I did not find any reference to this in the mail archives, although
> Googling did give, for a non-Apache context, a suggestion it was due to
> the order of parameters in the gcc command line. Hence the gcc version
> number above.
>
> Any ideas?
I don't have a solution at hand, but maybe the info I can provide helps
tracking down the problem: Up to Perl 5.8.8 if one wanted to link a
program dynamically against libperl.so you also had to link your
software statically against DynaLoader.a.
("-lperl /lib/auto/DynaLoader/DynaLoader.a").
For newer Perl versions this is no longer necessary but when doing so
will cause the musings about "boot_DynaLoader".
Maybe you compile/link with one and run with another perl installation?
hth
heiko
Re: Syntax error in mod_perl but not in shell command
As far as I understand it, mod_perl will eval{} the code it's going to
run and in the paragraph "Limitations" on
http://search.cpan.org/~rgarcia/Switch-2.13/Switch.pm
we're told that "Due to the way source filters work in Perl, you can't
use Switch inside an string eval.".
heiko
Re: Apache2::Request undefined symbol
Am Montag, den 07.07.2008, 08:31 +1000 schrieb Paul Cameron: > I installed the library package 'libapreq2' on an Ubuntu 7.10 distro, > and tried dereferencing the 'Apache2::Request' module in a mod_perl > script, but it crashed with '/usr/sbin/apache2: symbol lookup error: > > /usr/lib/perl5/auto/APR/Request/Apache2/Apache2.so: undefined symbol: > apreq_handle_apache2'. > > I ran 'nm' on libapreq2.so.3 and it returned > "nm: /usr/lib/libapreq2.so.3: no symbols". > > Can anyone help with this? Did you put LoadModule apreq_module modules/mod_apreq2.so in your httpd.conf? Heiko
Re: $r->connection->remote_ip with proxy and non proxy env
Am Mittwoch, den 08.10.2008, 10:06 -0700 schrieb Fred Moyer:
> You could also do something like:
>
> if (my $ip = $r->headers_in->{'X-Forwarded-For'}) {
>
> $r->connection->remote_ip( $ip );
> }
But (as I learned the hard way long ago) you should check the value of
the X-Forwarded-For header: On its way to you the request might have
passed other proxys which could also have contributed to that header
(putting anything in there from internal IPs to the string
"unknown"...).
IIRC, a frontend Apache proxy on your side appends (not prepends) the
remote ip it saw to the header (separated by ", ").
Heiko
Re: Setting LD_LIBRARY_PATH for a forked process
Am Freitag, den 09.01.2009, 10:25 +0100 schrieb Torsten Foertsch:
> On Fri 09 Jan 2009, Raymond Wan wrote:
> > It is possible I'm doing something wrong, but so far, this isn't
> > working. And if I replace the $cmd with a Perl script and try to
> > print out $ENV{LD_LIBRARY_PATH}, there is nothing.
>
> I think you need this one:
> http://search.cpan.org/~stas/Env-C-0.08/C.pm
Perhaps also possible: replace the program that gets executed with a
shell script that sets the env param and then does "exec realcmd $@".
Or even more simple: change the command string in your perl script to
something like 'LD_LIBRARY_PATH="..." realcmd'.
Of course that's far less elegant than using Env::C but I believe it
should work.
Heiko
