Re: problem with mod_perl 2.0 + apache 2.0 and proxyreq
John Chiu wrote: Thanks in advance. I've tried all the archives and google'd but I have not found anything that would help. I'm running RH 8.0, httpd-2.0.40-11.5 and mod_perl-1.99_05-3 from the RedHat distribution. I'm trying to create a small proxy module that will check a non-proxy request and depending on stuff dynamically transform it into a proxy request using mod_proxy. 1.99_05 is a way too old. Lots of bugs were fixed since that release. Upgrade to at least 1.99_09 or better the current cvs. 1.99_10 will be released as soon as perl-5.8.1 is released. I'm following the example in Chapter 7 (page 370) of the Writing Apache Modules with Perl and C. I know that the book is based on the older apache 1.3 server and associated mod_perl. However, I have not found anything in my readings to indicate that this would not work any more. my $r =3D shift; [... code snipped ...] BTW, you mailer has mangled the source code, s/=/=3D/ Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request. The apache error log indicates (with some debugging) that it is looping on the GET of goodbye.html. Additional debuging indicates that $r-proxyreq is always 0, so it's looping. My questions are: 1.Did sometime change in apache 2 or mod_perl 2 so that you cannot set proxyreq anymore: ie. $r-proxyreq(1). 2.How do you set proxyreq if $r-proxyreq(1) is not the correct method? 3.Is the logic wrong in this proxy example? How can we possible know what the problem is if you don't show the relevant configuration section? Most likely you have a broken configuration and should advise first the mod_proxy documentation. http://httpd.apache.org/docs-2.0/mod/mod_proxy.html To make sure that the problem is not in mod_perl, I've added a new modules/proxy test to the mp2 test suite, based on that example from the eagle book. Try it and if you succeed to break it, then we will fix it. You will need to retrieve the cvs version in order to get it. http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution (note: I have just committed the test, so if you use the snapshot, which is updated every 6 hours, it may not be there, so use the normal cvs checkout) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problem adding mod_perl to my web server config.
Paul Adair wrote: I recently attempted to add mod_perl to my web server configuration. Here is my current web server info. Apache/2.0.44 (Unix) mod_ssl/2.0.44 OpenSSL/0.9.7a DAV/2 PHP/4.3.1 Sun-ONE-ASP/4.0.0 There are no problems with this config and everything work ok. Paul, please make sure to follow the bug reporting guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I went through all of the config/setup docs on the web. I received an error while doing the make test. The error seemed to be tied with the mod_casp2 modules for Sun Chilisoft ASP. I figured maybe it has never tested it with this module so I proceeded with the make install. The make install seemed to go ok and it placed the mod_perl.so file in my apache2/modules directory. I then added the LoadModule mod_perl modules/mod_perl.so to my httpd.conf file. When attempting to start the web server I get the following error. you mean the one at the bottom of your bug report? I went through as much of the documentation that I could and I cannot find anything wrong at this time. Is there something else that needs to run at the end of the make test that my server did not complete because of the mod_casp2 problem? Is it possible that Apache::Test has picked mod_casp2 module from your already installed httpd's httpd.conf? Can you check whether you have the mod_casp2 module configured in t/conf/httpd.conf after you run: t/TEST -conf (that's after you've run 'make') If you have, does removing that entry allow the tests to start and pass? t/TEST (not 'make test', as it'll rewrite t/conf/httpd.conf again) __ 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: Problem adding mod_perl to my web server config.
/' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc -B/usr/ccs/bin/', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing' ccversion='', gccversion='3.1', gccosandvers='solaris2.8' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at Jul 22 2002 02:55:19 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/local/lib/perl5/5.8.0/sun4-solaris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Mon Apr 7 05:09:43 2003 GMT. -8-- End Bug Report --8-- - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Paul Adair [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, April 07, 2003 1:00 AM Subject: Re: Problem adding mod_perl to my web server config. Paul Adair wrote: I recently attempted to add mod_perl to my web server configuration. Here is my current web server info. Apache/2.0.44 (Unix) mod_ssl/2.0.44 OpenSSL/0.9.7a DAV/2 PHP/4.3.1 Sun-ONE-ASP/4.0.0 There are no problems with this config and everything work ok. Paul, please make sure to follow the bug reporting guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I went through all of the config/setup docs on the web. I received an error while doing the make test. The error seemed to be tied with the mod_casp2 modules for Sun Chilisoft ASP. I figured maybe it has never tested it with this module so I proceeded with the make install. The make install seemed to go ok and it placed the mod_perl.so file in my apache2/modules directory. I then added the LoadModule mod_perl modules/mod_perl.so to my httpd.conf file. When attempting to start the web server I get the following error. you mean the one at the bottom of your bug report? I went through as much of the documentation that I could and I cannot find anything wrong at this time. Is there something else that needs to run at the end of the make test that my server did not complete because of the mod_casp2 problem? Is it possible that Apache::Test has picked mod_casp2 module from your already installed httpd's httpd.conf? Can you check whether you have the mod_casp2 module configured in t/conf/httpd.conf after you run: t/TEST -conf (that's after you've run 'make') If you have, does removing that entry allow the tests to start and pass? t/TEST (not 'make test', as it'll rewrite t/conf/httpd.conf again) __ 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: Problem with mod_perl and subroutines in multiple files.
Benjamin Grabkowitz wrote: I am a new Perl developer and just found out about the great benefits of mod_perl. I see that you try to work with mod_perl 2.0. So here is a bit of advice: mod_perl 2.0 (1.99_0x) while getting better every day, still has quite a few bugs, so you may want to start with the stable mod_perl 1.0 (1.27) instead and then move on to 2.0 when the time comes. If you do want to stick with mp2, (and we do want people to start using it to expose the bugs as early as possible), please make sure to use the latest cvs version, since what you use is a way too old and lots of bugs were fixed since 1.99_05. See: http://perl.apache.org/download/source.html#mod_perl_2_0 Finally regarding your original question, you probably need to read this: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs and may be spend some time around http://perl.apache.org/docs/1.0/guide/ for your own good ;) I had a Perl cgi script that ran fine. It consisted of 1 main.pl file and multiple subroutines that each had their own file in a directory called libs (it is in the same directory as main.pl). When I got mod_perl properly configured (or to what I thought was properly configured), I got strange errors like: ModPerl::PerlRun: Not a CODE reference at /var/www/cgi-bin/main.pl line 31. __ 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: Problem compiling mod_perl 1.27 on Windows
Randy Kobes wrote: On Mon, 16 Dec 2002, Steve Hay wrote: Is there some other way, for Win32, to achieve what the PERL_USELARGEFILES=0 hack tried to do? This seems hard to do without recompiling either the standard Apache sources (to enable large_files support) or else the standard ActivePerl 8xx sources (to disable large_files support). Sounds like recompiling Perl from the ActivePerl 804 sources with large_files support disabled is my best bet. Am I correct in thinking that all I need to do to achieve this is change uselargefiles='define' back to uselargefiles='undef' in win32/config.vc, or is there anything else that I need to fiddle with too? - Steve
Re: Problem compiling mod_perl 1.27 on Windows
On Tue, 17 Dec 2002, Steve Hay wrote: Randy Kobes wrote: On Mon, 16 Dec 2002, Steve Hay wrote: Is there some other way, for Win32, to achieve what the PERL_USELARGEFILES=0 hack tried to do? This seems hard to do without recompiling either the standard Apache sources (to enable large_files support) or else the standard ActivePerl 8xx sources (to disable large_files support). Sounds like recompiling Perl from the ActivePerl 804 sources with large_files support disabled is my best bet. That would most probably fix the problem with mod_perl. Doing this may lead to an incompatibility in principle with trying to use a particular ppm package (having an xs component) provided by ActiveState, but since you have a compiler, that's not a problem for you. Am I correct in thinking that all I need to do to achieve this is change uselargefiles='define' back to uselargefiles='undef' in win32/config.vc, or is there anything else that I need to fiddle with too? I'm not sure Probably the safest thing to do is to compare the relevant files (Makefile, config*, *.h) under the win32/ subdirectory of the ActivePerl sources with those in the CPAN Perl sources. -- best regards, randy
Re: Problem compiling mod_perl 1.27 on Windows
On Mon, 16 Dec 2002, Steve Hay wrote: Hi, I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl 5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5). It builds fine with Perl 5.8.0 standard sources, but I'm just trying to upgrade my Perl to the slightly patched sources that ActivePerl Build 804 uses. I've built Perl from these new sources with the same build options that I used before for the standard source build (no threading, and Perl's malloc). (The output of Perl -V is at the bottom of this mail.) I run the following commands to build mod_perl: perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI nmake The first command runs fine, but the second has the following error: Apache.xs(1963) : error C2115: '=' : incompatible types The line referred to by this error is: statcache = r-finfo; I've no idea why this should be causing a problem with the new Perl. If I switch the Perl that I'm building against back to the standard 5.8.0 (by simply re-naming directories) and then re-run the nmake command above then mod_perl compiles and links with no errors. Can anyone shed any light on this? - Steve [ .. ] Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES I've found the same thing - I believe it's because of the USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this runs into a conflict with the standard Win32 apache-1 which doesn't have such support (in the above, statcache is from the Perl side, and r-finfo is from Apache). This is still being looked into ... One possibility is to recompile Apache with large_file support, but this is non-trivial. And since the bulk of Win32 development on Apache is going into Apache-2, it may be hard to get an Apache developer to look at this. By the way, mod_perl-2 (for use with Apache2) compiles fine with the ActivePerl sources. -- best regards, randy kobes
Re: Problem compiling mod_perl 1.27 on Windows
Randy Kobes wrote:
On Mon, 16 Dec 2002, Steve Hay wrote:
I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl
5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5).
It builds fine with Perl 5.8.0 standard sources, but I'm just trying to
upgrade my Perl to the slightly patched sources that ActivePerl Build
804 uses. I've built Perl from these new sources with the same build
options that I used before for the standard source build (no threading,
and Perl's malloc). (The output of Perl -V is at the bottom of this
mail.)
[ .. ]
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
I've found the same thing - I believe it's because of the
USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
runs into a conflict with the standard Win32 apache-1 which
doesn't have such support (in the above, statcache is from the
Perl side, and r-finfo is from Apache). This is still being
looked into ...
One possibility is to recompile Apache with large_file support,
but this is non-trivial. And since the bulk of Win32 development
on Apache is going into Apache-2, it may be hard to get an Apache
developer to look at this.
Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
uselargefiles_check() routine that originally warned about conflicts,
but now (as of 1.27, according to the Changes file) automatically sets
PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
that this seems to make is to stop Perl's $Config{ccflags} from being
appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
$Config{ccflags} doesn't mention anything to do with large_files, so
it's hardly surprising that disaster is not averted (if this is indeed
the problem).
Is there some other way, for Win32, to achieve what the
PERL_USELARGEFILES=0 hack tried to do?
I also see that the warning that was originally output by
uselargefiles_check() suggested re-building Apache with large_files
support by simply specifying a couple of extra defines. I take it from
what you're saying that it isn't quite as trivial as that on Win32?
By the way, mod_perl-2 (for use with Apache2) compiles fine with
the ActivePerl sources.
I've been reluctant to use mod_perl 2 for anything more than testing
purposes yet because its current version number (1.99_07) doesn't fill
me with confidence that it's sufficiently stable. The mod_perl setup
that I'm trying to build is destined for a production environment, so
I'd rather stick to more tried and tested things for now.
I would be interested to hear how stable people think mod_perl 2
currently is on Win32.
- Steve
Re: Problem compiling mod_perl 1.27 on Windows
On Mon, 16 Dec 2002, Steve Hay wrote:
Randy Kobes wrote:
I've found the same thing - I believe it's because of the
USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
runs into a conflict with the standard Win32 apache-1 which
doesn't have such support (in the above, statcache is from the
Perl side, and r-finfo is from Apache). This is still being
looked into ...
One possibility is to recompile Apache with large_file support,
but this is non-trivial. And since the bulk of Win32 development
on Apache is going into Apache-2, it may be hard to get an Apache
developer to look at this.
Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
uselargefiles_check() routine that originally warned about conflicts,
but now (as of 1.27, according to the Changes file) automatically sets
PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
that this seems to make is to stop Perl's $Config{ccflags} from being
appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
$Config{ccflags} doesn't mention anything to do with large_files, so
it's hardly surprising that disaster is not averted (if this is indeed
the problem).
That's true - Perl's ccflags don't mention USE_LARGE_FILES; it
only gets mentioned in the compile-time options.
Is there some other way, for Win32, to achieve what the
PERL_USELARGEFILES=0 hack tried to do?
This seems hard to do without recompiling either the standard
Apache sources (to enable large_files support) or else the
standard ActivePerl 8xx sources (to disable large_files support).
One possibility is to define one's own statcache (presently
defined in the header files under /Perl/lib/CORE/) as is defined
in a Win32 Perl without large_files support. That may get around
the problem in Apache.xs about incompatible types between
statcache and r-finfo, but this might lead to other problems
later.
I also see that the warning that was originally output by
uselargefiles_check() suggested re-building Apache with
large_files support by simply specifying a couple of extra
defines. I take it from what you're saying that it isn't quite
as trivial as that on Win32?
I tried just adding a couple of extra defines in compiling apache
- this starts a series of error messages in various C files about
incompatibilities, which then leads to having to put in a bunch
of #ifdef ... statemements. Ultimately this probably could be
worked out, but I'd be very uncomfortable using such a hacked
version without some official Apache support.
By the way, mod_perl-2 (for use with Apache2) compiles fine with
the ActivePerl sources.
I've been reluctant to use mod_perl 2 for anything more than testing
purposes yet because its current version number (1.99_07) doesn't fill
me with confidence that it's sufficiently stable. The mod_perl setup
that I'm trying to build is destined for a production environment, so
I'd rather stick to more tried and tested things for now.
I would be interested to hear how stable people think mod_perl 2
currently is on Win32.
That would be interesting
--
best regards,
randy
Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
On Thu, Apr 18, 2002 at 10:19:09AM -0700, Fernando Munoz wrote: Thanks for your input Stas. I followed (step-by-step) the installation suggested in the guide and I ended with the same message after .. # perl Makefile.PL USE_APACI=1 EVERYTHING=1 \ DO_HTTPD=1 SSL_BASE=/usr/local/ssl \ APACHE_PREFIX=/usr/local/apachessl \ APACHE_SRC=../apache_x.x.x/src \ APACI_ARGS='--enable-module=ssl,--enable-module=rewrite' . . . # make make test make install . . . ./gen_test_char test_char.h ld.so.1: ./gen_test_char: fatal: libssl.so.0.9.6: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target 'test_char.h' Current working directory /Repository/apache_1.3.24/src/main *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' I'm new with Solaris and it's starting to frustrate me. BTW I'm using binutils-2.11.2. Thanks for any help. I had this problem last week. If you *HAVE* libssl.so.0.9.6 on your system (which I assume you do, since you are using --enable-module=ssl), you need to make sure that ldconfig sets up your system's dynamic library paths properly or that your LD_LIBRARY_PATH environment variable has the correct directory in it. Go for the former, I'd say, but in my case, I merely did this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib And everything worked, because libssl had been previously installed with a prefix of /usr/local. -- \_/} Mark P. Fister Java, Java, everywhere, and all\_/} \_/} eBay, Inc. the cups did shrink; Java, Java\_/} \_/} Austin, TX everywhere, nor any drop to drink! \_/}
RE: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
Well I tried your suggestion and it didn't work at first but, after revising my steps I noticed that $LD_LIBRARY_PATH did not have /usr/local/ssl/lib (where libssl libraries live) so I push that path there and ssl passed. Unfortunately I got a different problem now .. === src/modules/ssl === src/modules/perl make: Fatal error: Don't know how to make target 'all' Current working directory /Repository/apache_1.3.24/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target 'all' Current working directory /Repository/apache_1.3.24/src/modules *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' It seems that I'm closer but not there yet. Thanks -Original Message- From: Mark P. Fister [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 10:39 AM To: Fernando Munoz Cc: 'Stas Bekman'; '[EMAIL PROTECTED]' Subject: Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp ! On Thu, Apr 18, 2002 at 10:19:09AM -0700, Fernando Munoz wrote: Thanks for your input Stas. I followed (step-by-step) the installation suggested in the guide and I ended with the same message after .. # perl Makefile.PL USE_APACI=1 EVERYTHING=1 \ DO_HTTPD=1 SSL_BASE=/usr/local/ssl \ APACHE_PREFIX=/usr/local/apachessl \ APACHE_SRC=../apache_x.x.x/src \ APACI_ARGS='--enable-module=ssl,--enable-module=rewrite' . . . # make make test make install . . . ./gen_test_char test_char.h ld.so.1: ./gen_test_char: fatal: libssl.so.0.9.6: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target 'test_char.h' Current working directory /Repository/apache_1.3.24/src/main *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' I'm new with Solaris and it's starting to frustrate me. BTW I'm using binutils-2.11.2. Thanks for any help. I had this problem last week. If you *HAVE* libssl.so.0.9.6 on your system (which I assume you do, since you are using --enable-module=ssl), you need to make sure that ldconfig sets up your system's dynamic library paths properly or that your LD_LIBRARY_PATH environment variable has the correct directory in it. Go for the former, I'd say, but in my case, I merely did this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib And everything worked, because libssl had been previously installed with a prefix of /usr/local. -- \_/} Mark P. Fister Java, Java, everywhere, and all\_/} \_/} eBay, Inc. the cups did shrink; Java, Java\_/} \_/} Austin, TX everywhere, nor any drop to drink! \_/}
Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
Fernando Munoz wrote: Well I tried your suggestion and it didn't work at first but, after revising my steps I noticed that $LD_LIBRARY_PATH did not have /usr/local/ssl/lib (where libssl libraries live) so I push that path there and ssl passed. Unfortunately I got a different problem now .. === src/modules/ssl === src/modules/perl make: Fatal error: Don't know how to make target 'all' Current working directory /Repository/apache_1.3.24/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target 'all' Current working directory /Repository/apache_1.3.24/src/modules *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' It seems that I'm closer but not there yet. Thanks seems to me that you've run apache's ./configure again after you have configured mod_perl, which wiped off the modperl config. See if you didn't mess up with the order of things. You should have a Makefile and a bunch of modperl files in src/modules/perl after you run 'perl Makefile ...' __ 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: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
Thank you very much Stas and Mark !... Everything went fine and I have a fresh Apache+mod_perl+mod_ssl running is this box. I noticed though that after rebooting I need to push again the path into $LD_LIBRARY_PATH for apache to run ??? any suggestion ?. But again Thanks so much. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 11:23 AM To: Fernando Munoz Cc: 'Mark P. Fister'; '[EMAIL PROTECTED]' Subject: Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp ! Fernando Munoz wrote: Well I tried your suggestion and it didn't work at first but, after revising my steps I noticed that $LD_LIBRARY_PATH did not have /usr/local/ssl/lib (where libssl libraries live) so I push that path there and ssl passed. Unfortunately I got a different problem now .. === src/modules/ssl === src/modules/perl make: Fatal error: Don't know how to make target 'all' Current working directory /Repository/apache_1.3.24/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target 'all' Current working directory /Repository/apache_1.3.24/src/modules *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' It seems that I'm closer but not there yet. Thanks seems to me that you've run apache's ./configure again after you have configured mod_perl, which wiped off the modperl config. See if you didn't mess up with the order of things. You should have a Makefile and a bunch of modperl files in src/modules/perl after you run 'perl Makefile ...' __ 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: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please Help !
Fernando Munoz wrote: These are the software/platform I'm working with: Solaris 8 Perl 5.6.1 OpenSSl-0.9.6c mod_ssl-2.8.8-1.3.24 mod_perl-1.24_01 Apache 1.3.24 These are the steps that I've taken to install the modules: Try to follow the exact steps described here: http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ it seems like you've messed some of these __ 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: Problem comping mod_perl and mod_dav statically at same time...
Hi All, To all those that read the message and were about to reply, a big thankyou. I *think* i have it working :-) The problem was that the 'dav' directory (as specificied in the Location field in my httpd.conf) did not exist on the filesystem!!! Once i created that, all the options seem to be available, and the Allow headers is perfect. cheers, simran. On Thu, 2002-03-14 at 19:29, simran wrote: Hi All, I am trying to compile the following things together: * apache_1.3.23 * mod_dav-1.0.3-1.3.6 * mod_perl-1.26 If i compile apache with mod_dav OR mod_perl it works fine. However, if i compile them both in then httpd always segfaults as soon as i pass it any request. The way i configure before compiling is: ./configure --enable-module=all --activate-module=src/modules/perl/libperl.a --activate-module=src/modules/dav/libdav.a - My actual issue is that i want mod_perl working and mod_dav working properly - i don't really care about how they are linked (static is preferable but not necessary). If i compile only mod_perl in statically and then compile mod_dav as a DSO (.so) file. Then the server stats up, but unfortunately a: OPTION /dav/ HTTP/1.1 Host: my.host.com:80 Gives me the following response HTTP/1.1 200 OK Date: Thu, 14 Mar 2002 08:01:49 GMT Server: Apache/1.3.23 (Unix) DAV/1.0.3 mod_perl/1.26 Content-Length: 0 MS-Author-Via: DAV Allow: OPTIONS, MKCOL, PUT, LOCK DAV: 1,2,http://apache.org/dav/propset/fs/1 Content-Type: text/plain BUT the response i really want is one that includes the header: Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE, PROPFIND, PROPPATCH, COPY, MOVE, LOCK, UNLOCK Otherwise of course WebDav will not work properly... - The relevant section in my httpd.conf file is: # # Web Dav Stuff... # DAVLockDB /tmp/DAVLock DAVMinTimeout 600 Location /dav AuthName DAV Realm AuthType Basic AuthUserFile /home/simran/netchant/www/pa/conf/.htpasswd DAV On Options Indexes AllowOverride All #Limit GET POST PUT DELETE CONNECT OPTIONS PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK #Order allow,deny #Allow from all # #Order deny,allow # #Deny from all #/Limit LimitExcept GET HEAD OPTIONS require valid-user /LimitExcept /Location -- Can anyone please help me with the following: --- * Compiling mod_perl and mod_dav staticaly together and ensuring apache does not die on any request or * Compiling mod_perl statically and mod_dav dynamically but getting apache to return the right Allow: headers so webdav actually works. Your help would be so very very much appreciated, i have been playing with this for over 3 full days and have not gotten very far at all. thanks, simran.
Re: Problem building mod_perl 1.26
Nevermind - I did a make distclean and started over, and now the problem's gone. I still wonder what it means though. --Bill. William R Ward writes: This is weird... anyone ever seen this before? In the middle of compiling the modules, I get syntax errors in the C code?? --Bill. /opt/SUNWspro/bin/cc -c -I/usr/local/include -O-DVERSION=\1.00\ -DXS_VERSION=\1.00\ -KPIC -I/usr/local/lib/perl5/5.00503/sun4-solaris/CORE Leak.c Leak.c, line 165: undefined symbol: aTHX_ Leak.c, line 165: syntax error before or at: Usage: Apache::Leak::NoteSV(obj) Leak.c, line 169: undefined symbol: dXSTARG Leak.c, line 176: undefined symbol: XSprePUSH Leak.c, line 176: undefined symbol: targ Leak.c, line 176: warning: improper pointer/integer combination: arg #1 Leak.c, line 176: left operand of - must be pointer to struct/union Leak.c, line 176: warning: improper pointer/integer combination: arg #1 Leak.c, line 176: warning: improper pointer/integer combination: op = Leak.c, line 185: undefined symbol: aTHX_ Leak.c, line 185: syntax error before or at: Usage: Apache::Leak::CheckSV(obj) Leak.c, line 187: syntax error before or at: hash_ptr Leak.c, line 189: undefined symbol: dXSTARG Leak.xs, line 171: undefined symbol: RETVAL Leak.c, line 194: undefined symbol: XSprePUSH Leak.c, line 194: undefined symbol: targ Leak.c, line 194: warning: improper pointer/integer combination: arg #1 Leak.c, line 194: left operand of - must be pointer to struct/union Leak.c, line 194: warning: improper pointer/integer combination: arg #1 Leak.c, line 194: warning: improper pointer/integer combination: op = Leak.c, line 203: undefined symbol: aTHX_ Leak.c, line 203: syntax error before or at: Usage: Apache::Leak::check_arenas() cc: acomp failed for Leak.c -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
RE: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
-Original Message- From: Matthew H. Gerlach [mailto:[EMAIL PROTECTED]] Now that I had something reproducible, I continued. I rebuilt using Apache 1.3.22 just like above, and everything continued to work. I upgraded to XML::Parser-2.30, and things continued to work. It was only when I went from perl 5.005_3 to 5.6.1 did my module break. As I said above I tried a statically linked apache. I also tried building Apache 1.3.22 as above with perl 5.6.1 and my code failed with both XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried using perl 5.6.1 I had my nasty problem. When configuring Apache 1.3.22 I noticed it said it was using the system's libexpat which was installed with RH. XML::Parser-2.29 uses its own copy of expat, but XML::Parser-2.30 uses the system libexpat. As I said with perl 5.005_3 I was able to use either version of XML::Parser. From what I can tell from the Apache 1.3.22 build, here's how to get it stable: 1. Install libexpat. 2. Install perl 3. Install XML::Parser 2.30 4. Install mod_perl and Apache, telling mod_perl to build Apache for you. ** Do not use APXS to build mod_perl ** The recipe in the AxKit INSTALL file seems to work best for people doing XML stuff inside mod_perl: $ perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ DYNAMIC=1 \ APACHE_PREFIX=/opt/apache \ APACHE_SRC=../apache_1.3.22/src \ DO_HTTPD=1 \ APACI_ARGS=--enable-module=so --enable-shared=info --enable-shared=proxy --enable-shared=rewrite --enable-shared=log_agent $ make $ su $ make install However, that also builds Apache with --disable-rule=expat, so it might kinda defeat your purpose :-) If you *really* need the expat in Apache, I think you can add in there --enable-rule=expat, but I haven't tried it. If all that fails, switch to XML::LibXML or XML::SAX::PurePerl (actually, think about doing that anyway :-) Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Just to follow up. I took your advice on building building modperl. My actual command was as follows: perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ APACHE_PREFIX=/lsurf/wohg \ APACHE_SRC=../$APACHE/src \ DO_HTTP=1 \ APACI_ARGS=--enable-rule=expat --enable-module=so --enable-shared=info \ --enable-shared=proxy --enable-shared=rewrite I first tried this with perl 5.005_3 with no problems. I then upgraded to perl 5.6.1, reinstalled the XML::Parser 2.30, and rebuild modperl/apache. The nasty bug showed back up. At this point it still looks like I'm SOL using XML::Parser with perl 5.6.1 under modper. I did download and install XML::LibXML and started playing with it. I'm actually using XML::Parser via XML::Simple to put short XML messages into handy 'data structures'. Maybe I should make an XML::LibXML::Simple :) Thanks for the help, Matthew Matt Sergeant wrote: -Original Message- From: Matthew H. Gerlach [mailto:[EMAIL PROTECTED]] Now that I had something reproducible, I continued. I rebuilt using Apache 1.3.22 just like above, and everything continued to work. I upgraded to XML::Parser-2.30, and things continued to work. It was only when I went from perl 5.005_3 to 5.6.1 did my module break. As I said above I tried a statically linked apache. I also tried building Apache 1.3.22 as above with perl 5.6.1 and my code failed with both XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried using perl 5.6.1 I had my nasty problem. When configuring Apache 1.3.22 I noticed it said it was using the system's libexpat which was installed with RH. XML::Parser-2.29 uses its own copy of expat, but XML::Parser-2.30 uses the system libexpat. As I said with perl 5.005_3 I was able to use either version of XML::Parser. From what I can tell from the Apache 1.3.22 build, here's how to get it stable: 1. Install libexpat. 2. Install perl 3. Install XML::Parser 2.30 4. Install mod_perl and Apache, telling mod_perl to build Apache for you. ** Do not use APXS to build mod_perl ** The recipe in the AxKit INSTALL file seems to work best for people doing XML stuff inside mod_perl: $ perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ DYNAMIC=1 \ APACHE_PREFIX=/opt/apache \ APACHE_SRC=../apache_1.3.22/src \ DO_HTTPD=1 \ APACI_ARGS=--enable-module=so --enable-shared=info --enable-shared=proxy --enable-shared=rewrite --enable-shared=log_agent $ make $ su $ make install However, that also builds Apache with --disable-rule=expat, so it might kinda defeat your purpose :-) If you *really* need the expat in Apache, I think you can add in there --enable-rule=expat, but I haven't tried it. If all that fails, switch to XML::LibXML or XML::SAX::PurePerl (actually, think about doing that anyway :-) Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Matthew H. Gerlach wrote: Just to follow up. I took your advice on building building modperl. My actual command was as follows: perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ APACHE_PREFIX=/lsurf/wohg \ APACHE_SRC=../$APACHE/src \ DO_HTTP=1 \ APACI_ARGS=--enable-rule=expat --enable-module=so --enable-shared=info \ --enable-shared=proxy --enable-shared=rewrite I first tried this with perl 5.005_3 with no problems. I then upgraded to perl 5.6.1, reinstalled the XML::Parser 2.30, and rebuild modperl/apache. The nasty bug showed back up. At this point it still looks like I'm SOL using XML::Parser with perl 5.6.1 under modper. I did download and install XML::LibXML and started playing with it. I'm actually using XML::Parser via XML::Simple to put short XML messages into handy 'data structures'. Maybe I should make an XML::LibXML::Simple :) i would say that XML::LibXML is the most stable modules ive used everything else perl has failed for the X3D parsing tool i made: http://drfrog.fdns.net/perl/parsex3d.pl this will have a much nicer home at web3d.org at some point soon they found a bug in it on freebsd timezone related iirc
Re: problem with mod_perl and scripts .... please help!!!
"aa" == abhishek agrawal [EMAIL PROTECTED] writes: aai am sure that i have installed the module Date::Calc properly using aappm. I dont know why is it giving this error. Is their some problem aausing Activeperl and modperl together? Obviously not, though. What happens when you run perl -MDate::Calc -e 'print $Date::Calc::VERSION' on a command line? Is that the same perl you had when you built mod_perl? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Problem Building Mod_Perl 1.24_01 under AIX and gcc
On Tue, Dec 05, 2000 at 03:50:00PM -0600, William R. Mattil wrote: IBM RISC 6000 gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) apache_1.3.14 mod_perl-1.24_01 perl is perl-5.6.0 mod_perl - $ cd mod_perl-1.XX $ perl Makefile.PL \ APACHE_SRC=../apache_1.3.X/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ [...] $ make $ make test $ make install $ cd apache_1.3.X $ ./configure \ --prefix=/path/to/install/of/apache \ --activate-module=src/modules/perl/libperl.a \ [...] $ make results in: cd ..; gcc -DAIX=42 -U__STR__ -DAIX_BIND_PROCESSOR -DMOD_PERL -DUSE_PERL_SSI -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -fno-strict-aliasing -I/usr/local/include -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -I. -I/usr/local/lib/perl5/5.6.0/aix/CORE -lm -o helpers/dummy helpers/dummy.c -Xlinker -bE:/usr/local/lib/perl5/5.6.0/aix/CORE/perl.exp -L/usr/local/lib /usr/local/lib/perl5/5.6.0/aix/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/aix/CORE -lperl -lnsl -ldbm -ldl -lld -lm -lc -lbsd -lPW -liconv -bE:./modules/perl/mod_perl.exp gcc: installation problem, cannot exec `cpp': No such file or directory gcc: file path prefix `/usr/local/lib/gcc-lib/E:./modules/perl/mod_perl.exp/egcs-2.91.60/' never used make: The error code from the last command is 1. You must compile all of perl, mod_perl and apache using the same compiler. In your case perl was compiled using the IBM C compiler, and the perl build procedure introduces compiler flags needed for mod_perl that are doing something completely different with gcc, causing the confusing error message. -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with mod_perl module!!!
Hi there, On Wed, 29 Nov 2000, Edmar Edilton da Silva wrote: How can I know if a perl script is being ran under mod_perl? http://perl.apache.org/guide 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with mod_perl module!!!
On Wed, 29 Nov 2000, Edmar Edilton da Silva wrote: I have a problem with the Apache::DBI and mod_perl modules that don't work together, before I thought that the problem was in the Apache::DBI. But, now I know that the problem is in the mod_perl because it also doesn't work when I try loading the CGI.pm module in the "startup.pl file". The conclusion is that when I don't load any module in the "startup.pl" file the perl scripts are ran correctly, but when I load some module the child processes (httpds) of the apache are not created. Thus, when a script is requested the server returns a message saying that the connection was refused. Sounds like your server didn't even start. Are you sure you compiled mod_perl into apache correctly? Check http://perl.apache.org/guide/ for instructions on how to figure that out. - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem building mod_perl on AIX with apxs DSO style
On Fri, Sep 15, 2000 at 10:42:19AM +, MJ M wrote: Hello, I am trying to build mod_perl on AIX with the apxs DSO style but get an error on link time. My config is: AIX-4.1.5 Make sure that you apply the following for AIX 4.2.1, you will get strange errors otherwise: --- src/support/httpd.exp.orig Wed Mar 1 16:35:34 2000 +++ src/support/httpd.exp Wed Mar 1 16:35:42 2000 @@ -1,4 +1,4 @@ -#! . +#! ap_MD5Encode ap_MD5Final ap_MD5Init Perl-5.6.0 with AIX patch distributed by Jens-Uwe Mager on this list a few months ago. Apache-1.3.12 mod_perl-1.24 I configured mod_perl with the command: perl Makefile.PL \ USE_APXS=1 \ EVERYTHING=1 \ WITH_APXS=/usr/local/apache/bin/apxs And I got the following error message after issuing a make: ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. ld: 0711-317 ERROR: Undefined symbol: ap_configtestonly make[1]: *** [libperl.so] Error 8 make[1]: Leaving directory `/u/mijmm/apache/mod_perl-1.24/apaci' make: *** [apxs_libperl] Error 2 There was some discussion about this on the new-httpd mailing list, and the consensus I think was to remove the reference to that symbol from mod_perl. I would believe if you use the current CVS sources of mod_perl then you do not see a reference to the symbol any more. Otherwise you can temporarily patch Apache like this: --- apache_1.3.12/src/support/httpd.exp.orig1 Mon Jun 12 01:01:11 2000 +++ apache_1.3.12/src/support/httpd.exp Mon Jun 12 01:01:53 2000 @@ -74,6 +74,7 @@ ap_clear_pool ap_clear_table ap_close_piped_log +ap_configtestonly ap_construct_server ap_construct_url ap_content_type_tolower -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED]
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Fri, 26 May 2000, Fred Miller wrote: Thank you very much. Sorry for being such a newbie. no need to apologize, this sort of problem isn't normal, if anyone should say sorry, it's sun for their flawed compiler kit. I rebuilt Perl with gcc, and then was able to get a build of Apache with mod_perl. great news.
RE: Problem with mod_perl
On Fri, 26 May 2000, Eugene S. Panenko wrote: Hi all, Sorry if it is an incorrect list to ask... I have a strange problem with mod_perl. I've tested mod_perl using a very simple scripts (one of them is attached). The network load is emulated via LAN using a special proggy. The problem is: under load above 20 requests per second after working some time (about 15-30 sec) Apache daemon stopts accepting new connections and blocks forever (without -X option httpd at this moment begin forking until it eats all resources) . I've found that the problem exists only when scripts use modules (tested with CGI v 2.46, IPC::Shareable, our own modules). Test scripts without modules work fine even under load of 200 requests per second. Without knowing too much about your apache config. files, machine specs, etc. I am guessing that your Apache MaxClients is still set at 150 (the out-of-the-box value). When apache receives a request that it cannot immediately handle (all of the pre-forked process are busy) it will fork another one (up to MaxClients). Eventually, you will run out of physical memory and begin to hit your swap space. When this happens, it takes longer to handle a request. That causes more requests to back up in the queue, so apache forks some more processes to handle the load. These new processes increase the amount of swapping that needs to be done, and the situation gets out of control. How many subprocesses you can support depends upon the size of your httpd process's text and data segments. I have seen several mod_perl applications increase the size of an httpd process to over 10 Mbytes. If you set MaxClients to a number that can be safely stored in physical memory (adjusting for the OS and other processes running on the machine, of course) you might eliminate your problem. -- Greg Estep [EMAIL PROTECTED]
Re: Problem with mod_perl
Hi there, On Fri, 26 May 2000, Eugene S. Panenko wrote: The problem is: under load above 20 requests per second after working some time (about 15-30 sec) Apache daemon stopts accepting new connections and blocks forever (without -X option httpd at this moment begin forking until it eats all resources) How much RAM in the machines? 73, Ged.
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
Doug MacEachern wrote: On Wed, 24 May 2000, Fred Miller wrote: Like I said, I'm a bit naive in these matters. I didn't specify using gcc or cc. I used the same path to compile Perl, Apache, and Mod_Perl. When I aaksed which gcc and which cc, my machine does report gcc appearing in my path ahead of cc. Could that be the problem? i could try re-building Perl like so: % ./Configure -des -Dcc=gcc make test make install that is, go with all the defaults, but force Perl to use gcc. Thank you very much. Sorry for being such a newbie. I rebuilt Perl with gcc, and then was able to get a build of Apache with mod_perl. Now to try and make this puppy learn a few tricks... I appreciate your help and patience. Best regards, Fred Miller -- [EMAIL PROTECTED] http://titan.iwu.edu/~fmiller/
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Wed, 24 May 2000, Fred Miller wrote: Like I said, I'm a bit naive in these matters. I didn't specify using gcc or cc. I used the same path to compile Perl, Apache, and Mod_Perl. When I aaksed which gcc and which cc, my machine does report gcc appearing in my path ahead of cc. Could that be the problem? i could try re-building Perl like so: % ./Configure -des -Dcc=gcc make test make install that is, go with all the defaults, but force Perl to use gcc.
Re: Problem: Apache/mod_perl/NT host won't close smtp connection
This is a follow-up to my previous post for anyone who might
have this problem and find this in the archives.
Firstly, the install was done correctly, I just lacked an
understanding of the directory hierarchies.
The version used in my original post was the binary
distribution of Apache+Perl+modperl from http://www.perl.com/CPAN/authors/Jeffrey_Baker/(perl-5_005_02+apache1_3_3+modperl-1_16-bin-bindist1-i386-win32-vc5.zip).
If you run the following command on the server, it will show an increasing value
for "Reset Connections" each time the email send fails:
C:\netstat -s
TCP Statistics
Reset
Connections
= 8I found old mod_perl list postings from Jun 1998
where the poster had the same problem but no solution.
I found a reference to another build in my mail
archives. I downloaded the Randy Kobes binary distribution from ftp://theoryx5.uwinnipeg.ca/pub/other/
and ran it. It has Perl-5.6.0, mod_perl-1.23, and Apache_1.3.12.
Even though it does not have everything we need, I set it up to see if the port
problem is there. The problem does not occur with this build.
We need Oracle drivers built in for our use, so we decided to
do our own build. It seamed inevitable that we would need to learn to do
this. I've built from source with Perl-5.6.0, mod_perl-1.24, and
Apache_1.3.12 and it does not have the problem. It seams to be OK and the
building went better than expected.
I have to assume the problem was caused somewhere in the
low-level socket code but not sure whose. The Microsoft web sites indicate
patches where made in the TCP code in each NT service pack.
Hope this helps somebody.
Chuck Goehring
[EMAIL PROTECTED]
-Original Message-From:
Chuck Goehring [EMAIL PROTECTED]To:
mod perl list [EMAIL PROTECTED]Date:
Monday, May 15, 2000 10:00 PMSubject: Problem:
Apache/mod_perl/NT host won't close smtp connection
Having a
problem where the connections to an smtp server doesn't seam to close
correctly on Windows NT. I've tried two separate mailing modules (MIME::Lite
and Mail::Sender). Neither will send a second time without re-starting Apache.
The Lite module uses the Net::smtp module and the Sender directly uses a
Socket (not IO::Socket). Additional details are listed further down. My
general question is: Are there problems with "PERL" Sockets on mod_perl/NT?
Since a nearly identical test program works from the PERL.exe command line it
seams as if mod_perl is trying to keep the port open or
something.
Also, there
are some directories that came with the Apache/mod_perl binary distribution
that have Socket.pm files in them. These directories are perl\lib\MSWin32-x86
and perl\lib\MSWin32-x86\IO. Should they have been copied over the other files
in the perl directory tree? Or, put in the startup.cgi(listing is at bottom)?
The distribution came with little docs and it was my first mod_perl
setup.
Any
infomation would be greatly appreciated.
Chuck
Goehring
[EMAIL PROTECTED]
Below are more details of the problem I've been
having.
--
Details:
I'm using
MIME::Lite to let users email files to other users as part of a document
management system. The MIME::Lite package inherits from Net::SMTP (@ISA =
qw(Net::SMTP);) and adds the capability to add attachments to the
email.
It works fine
the first time but gives an error the second time. If I run it external to the
site via the perl.exe command line (with use CGI lines removed), it works
flawlessly every time. Once the error starts, even leaving it overnight
doesn't allow it to work. It acts as though the socket doesn't get closed and
can't be reused. Below are the pertinant scripts.
--
MIME::Lite
sub to send via smtp:
sub
send_by_smtp {
my ($self,
@args) = @_;
# We need the
"From:" and "To:" headers to pass to the SMTP mailer:
my $hdr =
$self-fields();
my $from =
$self-get('From');
my @to =
$self-get('To');
# Create SMTP
client:
require
Net::SMTP;
my $smtp =
MIME::Lite::SMTP-new(@args)
or croak
"Failed to connect to mail server: $!";
$smtp-mail($from)
or croak
"SMTP MAIL command failed: $!";
$smtp-to(@to)
or croak
"SMTP RCPT command failed: $!";
$smtp-data()
or croak
"SMTP DATA command failed: $!";
# MIME::Lite
can print() to anything with a print() method:
$self-print($smtp);
$smtp-dataend();
$smtp-quit;
1;
}
--
The Error
from MIME::Lite:
[Sun May 14
16:20:10 2000] -e: Failed to connect to mail server: Bad file descriptor at
c:/apache/cgi-perl/test_sa_mime.cgi line 38 (Line 38 contains $SMTPRetVal =
$msg-send_by_smtp($SMTPhost, Timeout = 40);
--
Configuration:
Windows NT
service pack 4
Apache
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
Fred Miller wrote: Doug MacEachern wrote: looking at the line number, i would try replacing any occurance of: perl_eval_sv - eval_sv perl_call_sv - call_sv perl_call_pv - call_pv I wish I was experienced enough to know what this means. Now I think I'm starting to get confused. I tried building Apache and mod_perl by hand, loosely following some instructions I found on the web labeled "mod_perl installation". This part worked perl Makefile.PL APACHE_SRC=../apache_1.3.12/src NO_HTTPD=1 EVERYTHING=1 make make install All looked good I added to apache_1.3.12/src/Configuration addModule module/perl/libperl.a and the following EXTRA_LIBS and EXTRA_CFLAGS EXTRA_LIBS=`perl -MExtUtils::Embed -l ldopts` EXTRA_CFLAGS='perl -MExtUtils::Embed -e ccopts` I checked apache_1.3.12/src/modules/perl and a bunch of stuff had been put in there from my mod_perl build I then ran ./Configure form within apache_1.3.12/src - no problem but when I ran make, I received familiar errors: gcc -c -I../.. -I/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE -I../../os/unix -I../../include -DSOLARIS2=260 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED `perl -MExtUtils::Embed -e ccopts` mod_auth.c gcc -c -I../.. -I/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE -I../../os/unix -I../../include -DSOLARIS2=260 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED `perl -MExtUtils::Embed -e ccopts` mod_setenvif.c rm -f libstandard.a ar cr libstandard.a mod_env.o mod_log_config.o mod_mime.o mod_negotiation.o mod_status.o mod_include.o mod_autoindex.o mod_dir.o mod_cgi.o mod_asis.o mod_imap.o mod_actions.o mod_userdir.o mod_alias.o mod_access.o mod_auth.o mod_setenvif.o ranlib libstandard.a === modules/standard === modules/perl cc -O -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE -DMOD_PERL_VERSION=\"1.24\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24\" -I../.. -I/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE -I../../os/unix -I../../include -DSOLARIS2=260 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED `perl -MExtUtils::Embed -e ccopts` -c mod_perl.c "/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE/perl.h", line 1929: warning: operand treated as unsigned: 0x87654321 "./mod_perl.h", line 584: warning: macro replacement within a string literal "./mod_perl.h", line 587: warning: macro replacement within a string literal "./mod_perl.h", line 590: warning: macro replacement within a string literal "./mod_perl.h", line 593: warning: macro replacement within a string literal "mod_perl.c", line 347: fatal: macro recursion cc: acomp failed for mod_perl.c make[2]: *** [mod_perl.o] Error 2 make[1]: *** [all] Error 1 make: *** [subdirs] Error 1 Recommendations for how best to proceed? I find this quite curious, as I have Apache-1.3.12 working without mod_perl, and mod_perl seemed to build just fine separate from Apache. Thanks, Fred -- [EMAIL PROTECTED] http://titan.iwu.edu/~fmiller/
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Tue, 23 May 2000, Fred Miller wrote: On 4/26/2000, Steve Hay wrote about "Problem compiling mod_perl 1.23 on Solaris 2.4" I am experiencing what appears to be a very similar problem, but with more recent modules and OS. I am running mod_perl 1.24, Perl 5.6.0, Apache 1.3.12, Solaris 2.6 perl -V would help. is your cc gcc or sun's? looking at the line number, i would try replacing any occurance of: perl_eval_sv - eval_sv perl_call_sv - call_sv perl_call_pv - call_pv why your compiler is tripping on those macros, i have no idea.
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
John D Groenveld wrote:
-Xa is a Sun WorkShop Compiler C 4.2 option,
-X[a|c|s|t]
Specifies the degree of conformance to the ANSI C stan-
dard. Specifies one of the following:
a (ANSI)
ANSI C plus KR C compatibility extensions, with
semantic changes required by ANSI C. Where KR C
and ANSI C specify different semantics for the
same construct, the compiler will issue warnings
about the conflict and use the ANSI C interpreta-
tion. This is the default compiler mode.
The machine I was building on was Solaris 2.4 with the Sun Compiler v3.0
in which the cc manpage says "-Xt" ('transition') is the default. I
also have a Solaris 2.6 machine with the Sun Compiler v4.0 which says,
like the snippet above, that "-Xa" is the default.
Steve Hay
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
-Xa is a Sun WorkShop Compiler C 4.2 option, -X[a|c|s|t] Specifies the degree of conformance to the ANSI C stan- dard. Specifies one of the following: a (ANSI) ANSI C plus KR C compatibility extensions, with semantic changes required by ANSI C. Where KR C and ANSI C specify different semantics for the same construct, the compiler will issue warnings about the conflict and use the ANSI C interpreta- tion. This is the default compiler mode. John [EMAIL PROTECTED]
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
On Thu, 27 Apr 2000, Steve Hay wrote: Steve Hay wrote: I'm having a problem compiling mod_perl 1.23 (with Apache 1.3.12 / Perl 5.6.0) as a DSO using APXS on Solaris 2.4. In case anyone is interested... I've solved my own problem (just as well, really). If I re-compile everything with the -Xa compiler flag then it all works out fine. what does -Xa mean? gcc or ld flag? i don't see anything in the gcc manpage, 2.6 ld manpage says: Options No Longer Supported The following SunOS 4.x.y options do not have any replace- ment in this release: -B nosymbolic (this is now the default if -B symbolic is not used), -d, -dc, and -dp, (these are now the default; see -b above to override the default), -M, -S, -t, -x, -X, and -ysym. maybe that means -Xa is on by default in newer solaris?
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
Steve Hay wrote: I'm having a problem compiling mod_perl 1.23 (with Apache 1.3.12 / Perl 5.6.0) as a DSO using APXS on Solaris 2.4. In case anyone is interested... I've solved my own problem (just as well, really). If I re-compile everything with the -Xa compiler flag then it all works out fine.
RE: Problem compiling mod_perl 1.23 on Solaris 2.4
Good For you buddie:) We know that you can do that... ;) bybye Nazareno Perl Programmer www.obsequie.com
