[mp1.0] linking libperl.so fails because of G: command not found
Hello, I'd like to report an installation bug. I've looked around and if this has already been reported, or is mentioned in documentation, I apologize for the repeat. The symptom is when make tries to link libperl.so it dies with G: command not found I tracked down PERL_LD was blank in apaci/Makefile. I put gcc in there, and it linked and built properly. One one of the subsequent lines there was a -G at the start of PERL_LDDLFLAGS, so I assume that is where the G came from. Versions: SunOS 5.8 x86 apache 1.3.27 mod_perl 1.27 gcc version 2.95.3 20010315 (release) autoconf (GNU Autoconf) 2.53 GNU Make version 3.79.1 If there is any other information you need, please let me know. Kenny Smith JournalScape.com
ANNOUNCE: HTML::Mason 1.16
This is the latest action-packed release of HTML::Mason, with more bloody fights, steamy sex, and outrageous laughs than ever before. Thrill ... as an autohandler calls the next component in the chain. Tremble ... at the awesome might of the wicked dhandler. Cry ... for the humble subcomponent. This release fixes a bunch of bugs, including one potentially serious memory leak (if you created many Interp objects). It also includes a much rewritten version of the Admin Guide. Comments and suggestions on this are welcome for future releases. Have fun. Changes 1.16 December 13, 2002 [ ENHANCEMENTS ] - Documented behavior of $m-flush_buffer when a filter is present. - Turned off nowrap for error message on HTML error page. No more horizontal scrolling! - Substantially rewrote portions of the Admin Guide, in order to improve and clarify the portions related to configuring and customizing Mason under mod_perl. - Added back raw error on HTML error page. - Replaced FilesMatch with LocationMatch in docs and FAQ, because using FilesMatch means you can't use dhandlers. - Reduced memory usage when compiling large components. Memory usage for smaller components hasn't changed much, but they weren't really a problem in the first place. - Added a cgi_request method to the CGIHandler::Request object, which parallels the apache_req method offered by the ApacheHandler::Request object. [ BUG FIXES ] - When using the code cache within an Interp, a circular reference was created which prevented the Interp object from ever being destroyed. With Perl 5.6.0+, this will be automatically prevented by using weak references as needed. With Perl 5.00503, you will need to call the new Interp-flush_code_cache method in order to break the circular reference. This bug could cause memory leaks with code that created new Interp objects over time, though most uses of Mason do not do this. Reported by Kate Porter. - Fixed bad parsing of % $foo || 50 %. Mason was interpreting this as an escape flag. Escape flags now much match /^[[:alpha:]_]\w+/ and Mason specifically looks for || in a substitution as well. Reported by Kwindla Kramer. - If a dhandler one subdirectory down (like /foo/dhandler) called $m-decline, Mason threw a bogus exception. Fixed by Harmen. - Running the test suite caused an error in the shell on Win32 with newer versions of MakeMaker. Reported by Murat Unalan. (We _think_ this is fixed but we'd like confirmation from a Win32 user). - It was not possible to set the data_cache_defaults parameter from the httpd.conf file. Now it is. - Mason was using Apache::Request-new instead of Apache::Request-instance. This meant that if you had a handler that ran earlier (like a TransHandler) and that handler created an Apache::Request object, then the one Mason created would be missing any POST arguments. Reported by Ray Zimmerman. - Several different places in the docs said that Cache::Cache accepts a username option, but there is no such thing. - alter_superclass didn't work with CGIHandler because CGIHandler didn't define a $VERSION variable. Reported by Nadine and Harry Laxen. - Made CGIHandler merge together POST and query string arguments in order to be consistent with ApacheHandler. Reported by Nadine and Harry Laxen. - The CGIHandler module was overriding any out_method provided by the user. Reported by Nadine and Harry Laxen.
mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
Hello Happy Holidays, I'm also having trouble with mod_perl compiling. I know I risk RTFM replies. I just don't know where else to ask. If I'm missing some already posted info, please point me there and accept my appologies. I'll confess I'm very new to this but I've spent the past six months studying and building and resolving myriad confilcts and dependancies on this server: Red Hat v8.0 Apache v2.0.43 perl v5.8.0 gcc v 3.2 (2002 09 03) mod_perl 2.0 (nee 1.99_07) apr 0.9.1 apr-util 0.9.1 (I must confess that if I hadn't seen the rock-solid stability of xnix OS's I'd have given up long before now. The dependancy ride-go-'round with lib's and versions of gcc and required modules and varying versions of other OS components and programs has left me weary indeed and almost willing to give over the the dark side and consider M$ platforms instead of my LAMPS (Linux Apache MySQL PHP server). Please help a green accolyte keep his faith. The path of the way must challenge in order to foster growth and strength, but it must not crush nor kill.) In addition I've started from a clean install with updates (I do know this can be bad.) downloaded all of these components and updated from cvs today (13 DEC 2002). Yet... I receive the following after ./config'ing mod_perl: # make ... gcc -c -I/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/src/modules/perl -I /usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs -I/usr/local/apache2/2.0.4 3/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gd bm -DMOD_PERL -O2 -march=i386 -mcpu=i686 -DVERSION=\0.01\ -DXS_VERSION=\ 0.01\ -fpic -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE APR.c Running Mkbootstrap for APR () chmod 644 APR.bs rm -f ../../../blib/arch/Apache2/auto/APR/APR.so LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 make[3]: Leaving directory `/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs/APR/APR' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 #_ I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. When ./configure'ing the newest apr-util I get: #./configure ... ./configure: line 1278: syntax error near unexpected token `config.nice' ./configure: line 1278: `APR_CONFIG_NICE(config.nice)' #_ Mr. Bekman, can you kindly tell me what you recommend I get the latest cvs of? Did you mean mod_perl, libapr, Apache, or something else, or all of these? What was the broken build of? How do I mend it? I've tried the latest versions of these from CVS but get the same errors. Mr. Jensen, what did - if anything did - solve your problem? Thanks all for your kind consideration and in advance for any help you can provide. Your humble student, Daren Fairbanks
Stupid newbie question: where is .?
So, I'm using mod_perl as installed via RPMS on RedHat 8.0, and can't believe that an hour of hunting hasn't netted an answer to this apparently simple problem. Perl scripts seem not to have . set to ~user/public_html, as use() and require() fail on files which are in the same directory as the CGI script. What have I missed? The error message states that . is in @INC. To be specific, I've enabled mod_perl for ~user's files like this: Directory /home/user/public_html Options +Includes +ExecCGI AddHandler perl-script .pl PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders /Directory -- Stephen Walton, Professor, Dept. of Physics Astronomy, Cal State Northridge [EMAIL PROTECTED]
Re: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
D. Fairbanks wrote: [...] LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_perl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Stupid newbie question: where is .?
Stephen Walton wrote: Please state [mp2] or something in the subject or at least in the message so we don't have to guess what version you are talking about. So, I'm using mod_perl as installed via RPMS on RedHat 8.0, and can't believe that an hour of hunting hasn't netted an answer to this apparently simple problem. Perl scripts seem not to have . set to ~user/public_html, as use() and require() fail on files which are in the same directory as the CGI script. What have I missed? The error message states that . is in @INC. To be specific, I've enabled mod_perl for ~user's files like this: Directory /home/user/public_html Options +Includes +ExecCGI AddHandler perl-script .pl PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders /Directory Yes, ModPerl::Registry does *not* chdir to the script's dir in 2.0. Here is why: http://perl.apache.org/docs/2.0/user/coding/coding.html#Threads_Coding_Issues_under_mod_perl Various workarounds were discussed, but none were implemented so far. By the time mod_perl 2.0 is released we should sort it out. For now use mod_perl 1.0 if that's an issue to you. Of course you are more than welcome to sort this problem out and submit a patch for 2.0. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Cookie-free authentication
On Thu, 12 Dec 2002 14:29:16 -, Peter Werner wrote: hi all Hi Peter, et al [snip] i suppose it really depends on what you are developing, but take heed. i fully understand why cookie based authentication may be unacceptable, but consider maintainability and (long-term) scalability when you're doing your design and implementation. in the end you'll save someone a few grey hairs [snip] documentation :). however, it seems to me that (for clients that can support this implementation of Digest, which seems to be just about everyone but MSIE) the nonce provides exactly the kind of state information that is required for login/logout authentication. of course, it trades cookies for that pop-up box (again), so if you're looking for cookiless, HTML form based logins, then it's probably not what you want. All comments highly appreciated. It's a university environment, with MSIE on all PCs. Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL option working which munged URLs without requiring cookies. I've just upgraded to Apache V 2/Perl 5.8.0 and fought off a dept-wide Klez attack, with McAfee lying about having cleaned the machines, so one day soon I'll retry AuthCookieURL. -- Cheers Ron Savage, [EMAIL PROTECTED] on 14/12/2002 http://savage.net.au/index.html
Re: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
Is there a reason that we have to be this insulting? Beckman, I really expected more out of you. LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_pe rl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly.
How big are your httpd's?
Hi everyone, I would like to ask you how big your mod_perl enabled (v1) httpd's grow. I'm using a homegrown publication system based on Template Toolkit that delivers about 2000 Perl pages daily. After the first page load, the daemons consume around 7 MB of RAM each, but after 24 hours they've grown to something around 12 MB, with a record-holder of 16 MB. To me this seems like quite a lot, but I would like to get some numbers from other people as to what's normal. Thanks in advance, Axel Andersson
RE: Cookie-free authentication
On Sat, 14 Dec 2002, Ron Savage wrote: Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL option working which munged URLs without requiring cookies. I thought the problem was that Apache::AuthCookie was redirecting to your login scrip on logout instead of displaying your logout page. -- Bill Moseley [EMAIL PROTECTED]
Re: How big are your httpd's?
On Sat, Dec 14, 2002 at 04:50:25AM +0100, Axel Andersson wrote: Hi everyone, I would like to ask you how big your mod_perl enabled (v1) httpd's grow. I'm using a homegrown publication system based on Template Toolkit that delivers about 2000 Perl pages daily. After the first page load, the daemons consume around 7 MB of RAM each, but after 24 hours they've grown to something around 12 MB, with a record-holder of 16 MB. To me this seems like quite a lot, but I would like to get some numbers from other people as to what's normal. I don't know what's normal for other people, but with a personal Mason-driven site with only a few hundred visitors a day I get this: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 5661 www-data 9 0 15232 14M 9988 S 0.0 2.3 0:01 apache 2517 www-data 9 0 14256 13M 9984 S 0.0 2.1 0:01 apache 2518 www-data 9 0 14124 13M 9968 S 0.0 2.1 0:01 apache 2519 www-data 9 0 14076 13M 9968 S 0.0 2.1 0:01 apache 16638 www-data 9 0 14024 13M 9964 S 0.0 2.1 0:01 apache 26290 www-data 9 0 13948 13M 9948 S 0.0 2.1 0:00 apache 26289 www-data 11 0 13852 13M 9960 S 0.5 2.0 0:01 apache 2520 www-data 9 0 13816 13M 9816 S 0.0 2.0 0:01 apache 26288 www-data 9 0 13812 13M 9960 S 0.0 2.0 0:01 apache 18348 www-data 9 0 12692 12M 9904 S 0.0 1.9 0:01 apache 2996 root 9 0 12156 11M 10420 S 0.0 1.8 0:57 apache Linux 2.4.19 x86 SMP with 600 megs of RAM. I think your numbers are probably fairly normal. -- Nate Campi http://www.campin.net The basic notion underlying USENET is the flame. - Rospach, Chuq von msg31747/pgp0.pgp Description: PGP signature
Re: [mp2] make install quirk
[looks my original reply didn't make it through, trying again] Beau E. Cox wrote: Hi - I am posting this message informally - this is not critical (maybe not worth looking at); during the mp2 make install, mod_perl.so is copied to the apache2 tree (on my system) like this: cp mod_perl.so /usr/local/apache2/modules Now, if you haven't configured any apache2 modules (as I haven't for my test server), the subdirectory modules doesn't exist, so mod_perl.so is put into the apache2 tree as _file_ 'modules' under /usr/local/apache2. That's why I couldn't find it! [...] This is a known problem. I came up with this patch: http://marc.theaimsgroup.com/?l=apache-modperl-devm=103847596809386w=2 But I'm afraid it's not portable and hence I couldn't commit it. Here is the relevant snippet of the patch: install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) Any portability gurus know how to make this Makefile's line (the one with +) portable? I think 'mkdir' is portable. What about 'test -d'? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make install quirk
On Sat, 14 Dec 2002, Stas Bekman wrote: [looks my original reply didn't make it through, trying again] Beau E. Cox wrote: Hi - I am posting this message informally - this is not critical (maybe not worth looking at); during the mp2 make install, mod_perl.so is copied to the apache2 tree (on my system) like this: cp mod_perl.so /usr/local/apache2/modules Now, if you haven't configured any apache2 modules (as I haven't for my test server), the subdirectory modules doesn't exist, so mod_perl.so is put into the apache2 tree as _file_ 'modules' under /usr/local/apache2. That's why I couldn't find it! [...] This is a known problem. I came up with this patch: http://marc.theaimsgroup.com/?l=apache-modperl-devm=103847596809386w=2 But I'm afraid it's not portable and hence I couldn't commit it. Here is the relevant snippet of the patch: install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) Any portability gurus know how to make this Makefile's line (the one with +) portable? I think 'mkdir' is portable. What about 'test -d'? On Win32, at least, 'test' isn't available. What about something like the following: perl -e exit ! -d \$(MODPERL_AP_LIBEXECDIR)\ || mkdir $(...) (the \ may be needed if the directory contains spaces, as Win32 might). And if one is worried about the system mkdir availability, one can use perl -MExtUtils::Command -e mkpath directory -- best regards, randy
