Re: compiling modperl on alpha
Hi all, Just in case this may help others in coping with the install of mod_perl on Tru64, here are a few more info: After installing mod_perl 1.24_01 into Apache 1.3.14 statically on the DU4.0b system and getting it done all the way without errors besides the usual warnings, I found out that it really doesn't work. The perl in use on that system is 5.6 and I think it's the source of most troubles. I built mod_perl like this: CC="cc" export CC perl Makefile.PL \ APACHE_SRC=../apache/src \ EVERYTHING=1 \ PERL_TRACE=1 \ USE_APACI=1 \ DO_HTTPD=1 \ PREP_HTTPD=1 just like we should (I think), then did the make and make install but I skipped the make test, which never worked. I installed apache with modperl static and all other standard modules as DSOs, then added php4 as a DSO afterwards. PHP4 "kinda" worked because a simple page giving out its status info actually does work, but modperl doesn't. I don't really want to roll back perl on that system, it has too many users and too much traffic to mess with it that way. I did however try this same thing on the Tru64 5.1 system and same thing, PHP ended up working (at least for a while) but modperl just wouldn't work. So I rolled back to perl 5.00501 and did the whole thing from scratch, using the same script as above on the modperl side, with the make and make install (skipping test) then did the build of apache with: CC="cc" \ CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \ ./configure \ "--with-layout=config.mylayout:MyApache" \ "--activate-module=src/modules/perl/libperl.a" \ "--server-uid=httpd" \ "--server-gid=httpd" \ "--enable-module=most" \ "--enable-module=perl" \ "--enable-shared=max" \ "--disable-shared=perl" and a couple of other things like suexec. I haven't tried to use modperl as a DSO on that system again, so I'm not sure it would work or not. I also added PHP4 as a DSO after the install and that worked (also for a while) and modperl seems now to be working. The only problem I have to solve now is "why the heck did php work for a while then stopped working because of some unresolved symbol without changing anything in the config"! Beats me! I haven't found that out yet, even after re-building php from scratch again twice, it still won't work because of that un-resolved symbol "php_sig_gif". Other than that the modperl/apache tandem seems ok for now and I hope I can resolve this php thing without having to rebuild the whole thing. (if anyone knows about this un-resolved symbol, give me a hint..) But in any case, trying to use perl 5.6 is nothing but trouble and if someone has been able to make all this work with it, I'd like to know how! -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
on 11/19/00 4:55 PM, Ime Smits at [EMAIL PROTECTED] uttered the following:
| How do we make sure regular CGI scripts are using mod_perl???
| Is there a way to find out?
Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Can I assume that whenever mod_perl is enabled that all existing perl
scripts use it without any modification of any kind?
I tried this in a simple script on both systems where I installed mod_perl
and there is nothing in that variable on either system.
Isn't there any way to find out if mod_perl actually works?
I see nothing special in any logs about this, but a status and info on
apache shows mod_perl enabled, and the few perl directives I inserted in the
httpd.conf aren't making a fuss, so I assume mod_perl is parsing them
properly...
--
Didier Godefroy
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
on 11/19/00 6:04 PM, Randal L. Schwartz at [EMAIL PROTECTED] uttered the following: Didier Can I assume that whenever mod_perl is enabled that all existing perl Didier scripts use it without any modification of any kind? Not at all. Apache::Registry is a good stop-gap, but you have to play by a number of useful and documented rules. When you're *really* good with mod_perl, you abandon Apache::Registry and move up to writing handlers or using embedded templating systems like EmbPerl, Mason, or Template Toolkit. At the moment, I'm just trying to get mod_perl to work and have users' scripts use it. I haven't had time to read docs on how to use it, only enough to get it going. Will it speed up regular scripts? Will it reduce the strain on system resources? Can I force existing scripts to use it with only a Files section? without modifying any scripts? How can I get confirmation that scripts are actually using it -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
Try getting rid of Perl 5.6 and using 5.005. This has worked for me and for several other folks running other flavors of Unix. Weird, but compiled 5.6 perl with default options does not mesh well with mod_perl, however I run Mandrake Linux, and 5.6 precompiled for this platform, seem to integrate into mod_perl somewhat seamlessly. I suppose if you want 5.6 with mod_perl you gotta ask Mandrake folks for compile time options. I finally got frustrated enough to try not using 5.6 and I had to install 5.005 in there, but it didn't make any difference, the tests on modperl still won't work. It always does the same thing, no matter which perl is being used, http starts and keeps running but the test on the warm up before doing the actual tests always fails and there is nothing in the error log of any use. What the heck is the problem with it? Nothing ever works as it says in the docs! Following the steps to the letter is always insufficient, there is always some tinkering to do and it's not that obvious to figure it out.. -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CGI scripts mod_perl
Quick (and maybe stupid) question(s): How do we make sure regular CGI scripts are using mod_perl??? Is there a way to find out? Is there anything to modify to make them work with mod_perl?? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 8:10 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the following: supported by ld. In order to get it to compile I edited $APACHE_SRC/src/modules/perl/Makefile after running configure and added the -rpath stuff without the comma to the LDFLAGS variables and removed all This is assuming a static compile, but I'm trying to do a dso now... Anyway, when I tried to do a static, I didn't get such ld errors, it compiled all the way and the problem was with the tests, which wouldn't even run because it found the httpd not working, although httpd was actually up and when it tries to do the tests, it starts it, waits for it to warm up and finds it running because it says "done" after a moment, so httpd does start, but once the tests try to check on httpd for the second time before actually running the tests, it gives an error because it can't get a reply from httpd. The log file doesn't give anything useful to track this down and the httpd that was started stays in there running... I would prefer having mod_perl static anyway, if I could get it to pass the tests, it would be a good thing... -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 8:35 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the following: When building static, I use the following: Configuring and compile mod_perl: $ perl Makefile.PL \ APACHE_SRC=../apache_x.x.x/src \ USE_APACI=1 \ DO_HTTPD=1 \ EVERYTHING=1 \ PREP_HTTPD=1 $ make That's exactly what I was doing, but the make test fails, and since I don't even know why and the tests didn't run, I didn't dare going to the next step.. I'll try it again, and if the test don't run, I'll still try to go ahead, but how can it be tested after install to make sure it works? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 1:20 PM, Jimi Thompson at [EMAIL PROTECTED] uttered the following: I suspect that this has something to do with using Perl 5.6.0. I and several others have had problems getting mod_perl to work with this version of Perl under various flavors of Unix (Solaris, AIX, HP-UX). We have all also found that if you roll Perl back to 5.005 that this appears to solve the problem. Actually, I just compiled mod_perl with apache (static) and bypassed the tests, I only did the make and install of mod_perl then did apache, doing no tests anywhere, and it worked!!! But I have to do some testing of the perl module, everything seems to work fine but I don't know if mod_perl will work right... The install I just did was on the older DU4.0b system, now I'll try the same thing on the new Tru64 5.1 and we'll see what happens. What would be a good enough test to make sure mod_perl works right? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
compiling modperl on alpha
More troubles in this saga to install mod_perl with apache: After building mod_perl static with apache on DU4.0b and getting no errors (so far), I tried the same thing on Tru64 5.1 and I'm still getting this: ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.l o perlio.lo mod_perl_opmask.lo Apache.lo Constants.lo ModuleConfig.lo Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.l o -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -L/usr/local/lib /usr/local/lib/perl5/5.6.0/alpha-dec_osf/auto/DynaLoade r/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -lperl -lbind -lgdbm -ldbm -ldb -lm -liconv ld: Invalid flag usage: Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE, -Wx,-option must appear after -_SYSTYPE_SVR4 ld: Usage: ld [options] file [...] I'm trying again to do it static, I thought that stuff wasn't used in the static build! What could be the difference between DU4.0b and Tru64 5.1 that could cause this? Both systems have Perl 5.6.0 installed (from source), I'm using cc and there is no GNU ld in either. Apache is 1.3.14 and mod_perl 1.24_01 -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 3:48 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the following: ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o For whatever reason, it's trying to build a dso. I'd double check my settings. You were right, it must be because I had --enable-shared=max in there, maybe it applied that to the extra mod_perl, so I added a --disable-shared=perl and that error is gone, and the make goes all the way now... -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache::Scoreboard
Hi all again, I was trying to add the Apache::Scoreboard module to perl using cpan and it's giving out errors: cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_protocol.h, line 153: Invalid declara tion. __attribute__((format(printf,2,3))); ^ cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_log.h, line 119: Invalid declaration. __attribute__((format(printf,5,6))); ^ cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_log.h, line 122: Invalid declaration. __attribute__((format(printf,5,6))); ^ cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_log.h, line 133: Invalid declaration. __attribute__((format(printf,2,3))); ^ is there a bug in that module? Or is there a way to get this to install anyway? (system is Alpha DU4.0b ) -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
Here is an other one: I finally got mod_perl statically compiled and installed with apache. I didn't run the tests on mod_perl as they fail every time, maybe it has something to do with what's going on now, I'm not sure. When I try to run one of those test scripts that come with apache in the cgi-bin, only the one with the shell works, not the perl one. I tried disabling suexec then mod_perl, but it doesn't change anything with both disabled. CGI works but not with perl, and I even tried it with tcl and the result is the same with tcl and with perl. Using bash or sh work fine. The perl script printenv runs manually on the system but not as a cgi. I checked and double checked the permissions and ownerships, especially since I was trying to get suexec enabled, I think I got all that right (I never used suexec before), but it makes no difference anyway, because I disabled it and it's the same thing. I looked of course in the error logs, including cgierrors, nothing useful there, it only reports a 500 error (premature end of script headers) and nothing more, even with loglevel at debug and the -w perl warnings on. What could I be missing??? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/16/00 8:50 PM, Jeremy A. Mates at [EMAIL PROTECTED] uttered the following: Make sure the ld that is being called is the exact same one that was used to build perl itself, e.g. by altering your PATH environment variable to point to either the vendor default first (under /usr/bin) or perhaps to the GNU ld that might have gotten installed somewhere under /freeware/bin or /usr/local/bin. GNU ld isn't on either system and the error is the exact same on both, they seem to all this in common: -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE' Configure script; you can run `perl -V` to show what the flags are on the perl binary earliest in your PATH. Changing the ld binary used or ld here it is: perl -V Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=dec_osf, osvers=4.0, archname=alpha-dec_osf uname='osf1 ulysium.ulysium.net v4.0 564 alpha ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=define use64bitall=define uselongdouble=define usesocks=undef Compiler: cc='cc', optimize='-O4', gccversion= cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C' ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=8, ptrsize=8, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=8, nvtype='long double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /var/shlib libs=-lbind -ldbm -ldb -lm -liconv libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE' cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES Built under dec_osf At first when I tried building mod_perl, it complained about the large file support no being in apache, so I recompiled apache for that. Also note that mod_perl as a DSO isn't recommended by the mod_perl documentation... What is the problem with doing that? I tried compiling it statically first, but I get other types of errors when running the tests, it always fails. The httpd is running but the tests won't, and the log doesn't say anything that helps to find out why. What other choices are there then? -- Didier Godefroy mailto:[EMAIL PROTECTED]
