Michael G Schwern wrote:

>On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote:
>
>
>>This patch finally fixes it for me:
>>
>>
>
>I'm glad you guys got it working, but there's still the problem of why
>MakeMaker's behavior changed.  Since I tend not to touch the XS building
>code much its likely a bug.  Try the snapshot on makemaker.org.  I just
>fixed a minor issue with argument passing in recursive builds.
>
I just tried MM 6.13: that made no difference.

Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed
loads of its own tests, but made no difference to the libapreq build
process.

>
>If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out
>what's different.  Also, if you could try various alpha versions between
>those two, show the Makefiles and whether or not they exhibited the
>behavior that would help alot in narrowing it down.
>
>
I've also tried MM 6.05: that works OK.

Attached are the various Makefiles (the top-level one, plus those from
the c, Cookie and Request sub-directories), and a transcript of the
"nmake" step, from a build using MM 6.05 (which worked) and another
build using MM 6.12 (which failed).

I'll move on to trying out those alpha versions and get back to you on
which was the first one that failed.

Steve

Steve Hay wrote:

> Michael G Schwern wrote:
>
>
>>
>> If I could see the Makefiles from 6.03 and 6.12 I might be able to
>> figure out
>> what's different.  Also, if you could try various alpha versions between
>> those two, show the Makefiles and whether or not they exhibited the
>> behavior that would help alot in narrowing it down.
>>
>>
> I've also tried MM 6.05: that works OK.
>
> Attached are the various Makefiles (the top-level one, plus those from
> the c, Cookie and Request sub-directories), and a transcript of the
> "nmake" step, from a build using MM 6.05 (which worked) and another
> build using MM 6.12 (which failed).
>
> I'll move on to trying out those alpha versions and get back to you on
> which was the first one that failed.

This bug evidently goes back a long way:  MM 6.06_02 fails in the same
way as 6.13.

I tried to use MM 6.06_01, but it wouldn't build itself ("don't know how
to make 'C:\perl5\libNAME'").  Instead, I knife-and-forked it into
place, but when I tried to use it to build libapreq, I just got the same
error again - "don't know how to make 'C:\perl5\libNAME'".

So the best I can offer you at this stage is that something between 6.05
and 6.06_02 broke it.  (Probably not what you wanted to hear, I guess,
looking at the number of changes in 6.06_01.)

Steve

Steve Hay wrote:

> This bug evidently goes back a long way:  MM 6.06_02 fails in the same
> way as 6.13.
>
> I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> how to make 'C:\perl5\libNAME'").  Instead, I knife-and-forked it into
> place, but when I tried to use it to build libapreq, I just got the
> same error again - "don't know how to make 'C:\perl5\libNAME'".

OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
-- needed to change DIRFILESEP from \ to ^\, and fill in the missing
*PERLSAFE macros), and the bad news is that it doesn't build
libapreq-1.2 either!  I still get the "unresolved external symbol
boot_libapreq" error.

So it's one of the many changes between 6.05 and 6.06_01 that broke it.

Steve

On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
> >This bug evidently goes back a long way:  MM 6.06_02 fails in the same
> >way as 6.13.
> >
> >I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> >how to make 'C:\perl5\libNAME'").  Instead, I knife-and-forked it into
> >place, but when I tried to use it to build libapreq, I just got the
> >same error again - "don't know how to make 'C:\perl5\libNAME'".
>
> OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
> -- needed to change DIRFILESEP from \ to ^\, and fill in the missing
> *PERLSAFE macros), and the bad news is that it doesn't build
> libapreq-1.2 either!  I still get the "unresolved external symbol
> boot_libapreq" error.
>
> So it's one of the many changes between 6.05 and 6.06_01 that broke it.

Well, that narrows it down quite a bit.

Which version of mod_perl and Apache is this against and *exactly* what do
I have to do to exercise this bug?  I haven't built mod_perl in a long time.


--
I'll tell you what beats voodoo every time, a big ass knife.
	 -- "Overkill" Battlebot driver

On Fri, Aug 01, 2003 at 09:05:55AM +0100, Steve Hay wrote:
> I just tried MM 6.13: that made no difference.
>
> Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed
> loads of its own tests, but made no difference to the libapreq build
> process.

Oh yeah, I didn't update the snapshot.  Thanks for the reminder.


--
You can't control the universe with a jar of red pepper.
         http://www.goats.com/archive/981004.html

Michael G Schwern wrote:

>On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
>
>
>>>This bug evidently goes back a long way:  MM 6.06_02 fails in the same
>>>way as 6.13.
>>>
>>>I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
>>>how to make 'C:\perl5\libNAME'").  Instead, I knife-and-forked it into
>>>place, but when I tried to use it to build libapreq, I just got the
>>>same error again - "don't know how to make 'C:\perl5\libNAME'".
>>>
>>>
>>OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
>>-- needed to change DIRFILESEP from \ to ^\, and fill in the missing
>>*PERLSAFE macros), and the bad news is that it doesn't build
>>libapreq-1.2 either!  I still get the "unresolved external symbol
>>boot_libapreq" error.
>>
>>So it's one of the many changes between 6.05 and 6.06_01 that broke it.
>>
>>
>
>Well, that narrows it down quite a bit.
>
>Which version of mod_perl and Apache is this against and *exactly* what do
>I have to do to exercise this bug?  I haven't built mod_perl in a long time.
>
>
I'm using Apache 1.3.27, mod_perl 1.28, libapreq-1.2, but I'm on Windows
with MS VC++ 6.0, so this might not be very useful to you since you
haven't got such a setup yourself...  Anyway, here goes; it's probably
pretty similar on whatever OS you're on (perhaps with an extra
"./configure ..." line before the Apache "make"?)

- Unpack Apache, mod_perl, libapreq into C:\Temp
- cd to C:\Temp\apache_1.3.27\src
- Run "nmake /f makefile.win installr". That builds Apache and installs
it into C:\apache by default.
- cd to C:\Temp\mod_perl-1.28
- Run "perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules".
- Run "nmake", "nmake test", "nmake install" as usual.
- cd to C:\Temp\libapreq-1.2
- Run "perl Makefile.PL"
- Run "nmake" -- that fails with the "unresolved external symbol
boot_libapreq" error.

That's it.

BTW, I've been looking at the Makefiles that I sent previously, and have
found something interesting.  The Makefile in the "c" sub-directory from
the 6.05 build contains this:

=====================
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make dynamic"
#dynamic :: Makefile
dynamic :: Makefile
     @$(NOOP)
=====================

while the corresponding section from the 6.12 build contains this:

=====================
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make dynamic"
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
     $(NOECHO) $(NOOP)
=====================

If that's relevant, then the latter looks more likely to be correct,
doesn't it?  Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
the only problem here is that libapreq was previously relying on that bug?

Steve

Hi.

I need some help with handlers.

I'm a linux newbie.  I freshly installed RH 9.
I built perl 5.8.0 from source.

As non-root, I downloaded source for
Apache 1.3.28 and mod_perl 1.28
and built them, using the instructions here

http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl\
_Installation

I've also been using Stas' book, Practical Mod Perl,
and the mod_perl developer's cookbook.

The only change I made to the
A_Summary_of_a_Basic_mod_perl_Installation
was using SU to root for the make install for
mod_perl.

The resulting Apache runs fine.

The resuling mod_perl runs cgi-scripts fine.

At times I'm running two servers on the same box, one
listening
to port 80 and one listening to port 8080.
I turned off the ssl piece of both servers, as they
were colliding
on port (I think) 443.  I'm not sure if this 2 server
issue
or the turning ssl is relevant to my problem.

Now I'm trying to write my first mod_perl handler:

PerlModule Apache::HandlerTest
<Location /handlertest>
     SetHandler perl-script
     PerlHandler Apache::HandlerTest
  </Location>


package Apache::HandlerTest;
   # File is called Apache/HandlerTest.pm
   # Path:
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm

   sub handler {
       my $r = shift; # Apache session object
       $r->content_type('text/html');
       $r->send_http_header;
       $r->print( "Hello, world." );
   }


It dies with an

Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete your
request

Here's the end of the log


[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] Can't locate object method "content_type"
via package "Apache::RequestRec" at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 6.!
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error

As the problem seesm related to finding things, I
tried making
the handler simpler by using no functions

sub handler {
  print "HTTP/1.0 200 OK\n";
  print "Content-Type: text/html\n\n";
  print "<html><body>Hello</body></html>";
  return 200;
}

This didn't work either --

[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] Can't locate object method "PRINT" via
package "Apache::RequestRec" at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 13.!
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error

I guess the print is really a call to $r->print()
(Practical Mod_perl p 238).

This newcoming to mod-perl seeks any help on next
steps.

RKG

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Hi --

I'm following up on a previous message (below),
sorry to break the thread in two.
In my first post, I was wondering my handler didn't
work.  I said "make test" worked fine for mod_perl.

Well, maybe.

Here's the output.



aprk@sam:~/source/mod_perl-1.28> make test
(cd ../apache_1.3.28 &&
PERL5LIB=/home/aprk/source/mod_perl-1.28/lib: make)
make[1]: Entering directory
`/home/aprk/source/apache_1.3.28'
===> src
make[2]: Entering directory
`/home/aprk/source/apache_1.3.28'
make[3]: Entering directory
`/home/aprk/source/apache_1.3.28/src'
===> src/regex
make[4]: Nothing to be done for `all'.
<=== src/regex
===> src/os/unix
make[4]: Nothing to be done for `all'.
<=== src/os/unix
===> src/ap
make[4]: Nothing to be done for `all'.
<=== src/ap
===> src/main
make[4]: Nothing to be done for `all'.
<=== src/main
===> src/lib
<=== src/lib
===> src/modules
===> src/modules/standard
make[5]: Nothing to be done for `all'.
<=== src/modules/standard
===> src/modules/perl
make[5]: Nothing to be done for `all'.
<=== src/modules/perl
<=== src/modules
cc -c -I. -I/usr/local/lib/perl5/5.8.0/i686-linux/CORE
-I./os/unix -I./include   -DLINUX=22 -DMOD_PERL
-DUSE_PERL_SSI -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -DUSE_HSREGEX -DNO_DL_NEEDED
-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm `./apaci`
modules.c
cc -c -I. -I/usr/local/lib/perl5/5.8.0/i686-linux/CORE
-I./os/unix -I./include   -DLINUX=22 -DMOD_PERL
-DUSE_PERL_SSI -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -DUSE_HSREGEX -DNO_DL_NEEDED
-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm `./apaci`
buildmark.c
cc  -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI
-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
-DUSE_HSREGEX -DNO_DL_NEEDED -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm `./apaci`    \
       -o httpd buildmark.o modules.o
modules/standard/libstandard.a modules/perl/libperl.a
main/libmain.a ./os/unix/libos.a ap/libap.a
regex/libregex.a   -lm -lcrypt -rdynamic
-L/usr/local/lib
/usr/local/lib/perl5/5.8.0/i686-linux/auto/DynaLoader/DynaLoader.a
-L/usr/local/lib/perl5/5.8.0/i686-linux/CORE -lperl
-lnsl -ldl -lm -lc -lcrypt -lutil
make[3]: Leaving directory
`/home/aprk/source/apache_1.3.28/src'
make[2]: Leaving directory
`/home/aprk/source/apache_1.3.28'
make[2]: Entering directory
`/home/aprk/source/apache_1.3.28'
===> src/support
make[3]: Entering directory
`/home/aprk/source/apache_1.3.28/src/support'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/home/aprk/source/apache_1.3.28/src/support'
<=== src/support
make[2]: Leaving directory
`/home/aprk/source/apache_1.3.28'
<=== src
make[1]: Leaving directory
`/home/aprk/source/apache_1.3.28'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Apache'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Apache'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Connection'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Connection'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Constants'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Constants'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/File'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/File'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Leak'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Leak'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Log'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Log'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/ModuleConfig'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/ModuleConfig'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/PerlRunXS'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/PerlRunXS'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Server'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Server'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Symbol'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Symbol'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Table'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Table'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/URI'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/URI'
make[1]: Entering directory
`/home/aprk/source/mod_perl-1.28/Util'
make[1]: Leaving directory
`/home/aprk/source/mod_perl-1.28/Util'
cp t/conf/mod_perl_srm.conf t/conf/srm.conf
../apache_1.3.28/src/httpd -f `pwd`/t/conf/httpd.conf
-X -d `pwd`/t &
httpd listening on port 8529
will write error_log to: t/logs/error_log
letting apache warm up...\c
done
/usr/local/bin/perl t/TEST 0
modules/actions.......ok
modules/cgi...........ok
modules/constants.....ok
modules/cookie........skipped
         all skipped: no reason given
modules/file..........ok
modules/httpdconf.....ok
modules/include.......ok
modules/log...........ok
modules/module........skipped
         all skipped: no reason given
modules/perlrun.......ok
modules/psections.....skipped
         all skipped: no reason given
modules/request.......skipped
         all skipped: no reason given
modules/src...........ok
modules/ssi...........ok
modules/stage.........skipped
         all skipped: no reason given
modules/status........ok
modules/symbol........skipped
         all skipped: no reason given
modules/uri...........ok
modules/util..........ok
internal/api..........ok
internal/auth.........ok
internal/croak........ok
internal/dirmagic.....ok
internal/error........ok
internal/headers......ok
internal/hooks........ok
internal/http-get.....ok
internal/http-post....ok
internal/proxy........ok
internal/redirect.....ok
internal/rwrite.......ok
internal/stacked......ok
internal/table........ok
internal/taint........ok
All tests successful, 6 tests skipped.
Files=34, Tests=400, 24 wallclock secs (19.31 cusr +
1.50 csys = 20.81 CPU)
kill `cat t/logs/httpd.pid`
rm -f t/logs/httpd.pid
rm -f t/logs/error_log
aprk@sam:~/source/mod_perl-1.28>
aprk@sam:~/source/mod_perl-1.28>
aprk@sam:~/source/mod_perl-1.28>




Why did it skip 6 tests?

For example, module and request.

I think these skipped tests could be
what is causing my handlers to fail,
even though the server and my perl cgi works.

I have one dev box for development and one outside
box at an ISP.  I am getting these errors on the dev
box.  To see if the problem was my dev handler or my
dev conf files (vs. my dev mod_perl installation), I
tried the same handler on the outsider box and
got the same error.

Seeking suggestions & help --

RKG



===================
PREVIOUS POST
===================
Hi.

I need some help with handlers.

I'm a linux newbie. I freshly installed RH 9.
I built perl 5.8.0 from source.

As non-root, I downloaded source for
Apache 1.3.28 and mod_perl 1.28
and built them, using the instructions here

http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl\
_Installation


I've also been using Stas' book, Practical Mod Perl,
and the mod_perl developer's cookbook.

The only change I made to the
A_Summary_of_a_Basic_mod_perl_Installation
was using SU to root for the make install for
mod_perl.

The resulting Apache runs fine.

The resuling mod_perl runs cgi-scripts fine.

At times I'm running two servers on the same box, one
listening
to port 80 and one listening to port 8080.
I turned off the ssl piece of both servers, as they
were colliding
on port (I think) 443. I'm not sure if this 2 server
issue
or the turning ssl is relevant to my problem.

Now I'm trying to write my first mod_perl handler:

PerlModule Apache::HandlerTest
<Location /handlertest>
SetHandler perl-script
PerlHandler Apache::HandlerTest
</Location>


package Apache::HandlerTest;
# File is called Apache/HandlerTest.pm
# Path:
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm

sub handler {
my $r = shift; # Apache session object
$r->content_type('text/html');
$r->send_http_header;
$r->print( "Hello, world." );
}


It dies with an

Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete your
request

Here's the end of the log


[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] Can't locate object method "content_type"

via package "Apache::RequestRec" at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 6.!
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error

As the problem seesm related to finding things, I
tried making
the handler simpler by using no functions

sub handler {
print "HTTP/1.0 200 OK\n";
print "Content-Type: text/html\n\n";
print "<html><body>Hello</body></html>";
return 200;
}

This didn't work either --

[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] Can't locate object method "PRINT" via
package "Apache::RequestRec" at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 13.!
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error

I guess the print is really a call to $r->print()
(Practical Mod_perl p 238).

This newcomer to mod-perl seeks any help on next
steps.

RKG


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

> Sorry about this - I had a hard disc crash, and am just in
> the process of restoring things. Computers are getting too
> smart - they know when you're vulnerable, and will act
> accordingly ... Hopefully it'll be ready in a day.

No worries, things like these happen.

In the mean time, do you know of a mirror where I could get the files? I'm
trying to get mod_perl installed and get all the web scripts we have here
working on it, and I would like to be able to work on it today if
possible...

If not, I'll wait until Monday, no problem.

Thanks,

J-S

_______________________________________________
Jean-Sébastien Guay                  jean_seb@...
Software Developer, Hybride         http://www.hybride.com
Piedmont, Québec, Canada

Hi there,

On Fri, 1 Aug 2003, Tofu Optimist wrote:

> sorry to break the thread in two.

:(


> Why did it skip 6 tests?

How did you do the

perl Makefile.PL

step?

73,
Ged.

Exactly like it said in

http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl\
_Installation

% cd /usr/src
   % lwp-download
http://www.apache.org/dist/httpd/apache_1.3.xx.tar.gz
   % lwp-download
http://perl.apache.org/dist/mod_perl-1.xx.tar.gz
   % tar xzvf apache_1.3.xx.tar.gz
   % tar xzvf mod_perl-1.xx.tar.gz
   % cd mod_perl-1.xx
   % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \
     DO_HTTPD=1 USE_APACI=1 EVERYTHING=1
   % make && make test && make install
   % cd ../apache_1.3.xx
   % make install


--- Ged Haywood <ged@...> wrote:
> Hi there,
>
> On Fri, 1 Aug 2003, Tofu Optimist wrote:
>
> > sorry to break the thread in two.
>
> :(
>
>
> > Why did it skip 6 tests?
>
> How did you do the
>
> perl Makefile.PL
>
> step?
>
> 73,
> Ged.
>
>


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Hello again,

On Fri, 1 Aug 2003, Tofu Optimist wrote:

> --- Ged Haywood <ged@...> wrote:
>
> > How did you do the
> >
> > perl Makefile.PL
> >
> > step?
>
> % cd /usr/src
>   % tar xzvf apache_1.3.xx.tar.gz
>   % tar xzvf mod_perl-1.xx.tar.gz
>   % cd mod_perl-1.xx
>   % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src DO_HTTPD=1 USE_APACI=1
EVERYTHING=1

So your non-root user has write permission in /usr/src?  Hmmmm...

>   % make && make test && make install

This can't work, you need to be root to make install.

73,
Ged.

PS:
Did you build your own Perl?
Have you cleaned up any old Apaches and mod_perls?
(RH9 comes with Apache2, you probably want to get rid of that:).

Ged -- Sorry I wasn't fully explicit, it is still
early in the morning:

> So your non-root user has write permission in
> /usr/src?  Hmmmm...

Rather than /usr/src, I put in /home/aprk

>   % make && make test && make install
>  This can't work, you need to be root to make
> install.
>

Yes, you are correct.  make && make test as non-root,
then install as root.  (Odd, isn't it, the docs at
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl\
_Installation

don't make this explicit?)

> PS:
> Did you build your own Perl?

Yes, 5.8.0

> Have you cleaned up any old Apaches and mod_perls?
> (RH9 comes with Apache2, you probably want to get
> rid of that:).

Excellent point.   No.  There are probably hordes of
perls and hpptds and mod_perls running amok on the box
throwing wild parties;  I don't know.

I think my next step should be to start over fresh.
Again.

As a newbie, may I ask 4 basic questions:

[1] How do I find *everything* on the box related to
perl / apache / mod_perl, both 1 and 2, both the RH
install and from my own ftp / tar / make fumblings?

[2] How do I uninstall everything from [1], so I can
start fresh?

[3] I'd prefer to use modperl 2 and apache 2, as that
is what my ISP is using.  And I think I'd prefer to
use RH rpm to install them, as again, that is what my
ISP did.  (Want my dev box to match the outside box as
much as possible).  This newsgroup keeps mentioning
"build from sources," will I be going astray trying
the rpm route?

[4] Is a full uninstall enough, or should I reinstall
RH itself?

Many thanks for your generosity explaining these
mysteries to a newcomer.

-- A

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

On Fri, 2003-08-01 at 07:02, Tofu Optimist wrote:
> I'm a linux newbie.  I freshly installed RH 9.
> I built perl 5.8.0 from source.

Go and change your locale from UTF8 to en_US or C.  See this for why:
http://archive.develooper.com/perl5-porters@perl.org/msg97360.html

> As non-root, I downloaded source for
> Apache 1.3.28 and mod_perl 1.28
> and built them, using the instructions here
>
>
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl\
_Installation

Okay...

> [Thu Jul 31 18:34:08 2003] [error] [client
> 192.168.1.2] Can't locate object method "content_type"
> via package "Apache::RequestRec" at
> /usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
> line 6.!

That's mod_perl 2.  (There is Apache::RequestRec in mod_perl 1.)  You
must have an older one on your box and you are trying to run this
handler with it.  Figure out where you installed mod_perl 1 and use that
instead.

- Perrin

On Fri, 2003-08-01 at 10:31, Tofu Optimist wrote:
> [1] How do I find *everything* on the box related to
> perl / apache / mod_perl, both 1 and 2, both the RH
> install and from my own ftp / tar / make fumblings?

Well, you can run updatedb and then use locate to look for things like
apachectl and Apache.pm.

> [2] How do I uninstall everything from [1], so I can
> start fresh?

There is no simply way to uninstall software that you installed from
source.  There are things you can do though.  First uninstall any apache
or mod_perl rpms.  Then you can clear out all the Apach::* modules from
your perl lib, and delete all the web server stuff (which is typically
installed under a single directory).

> [3] I'd prefer to use modperl 2 and apache 2, as that
> is what my ISP is using.

Okay, then stop reading docs for mod_perl 1.

> And I think I'd prefer to
> use RH rpm to install them, as again, that is what my
> ISP did.

Don't do that.  mod_perl 2 is basically in alpha right now and changes
every day.  If you plan to run it, you must keep on top of development.
The rpms for mod_perl 2 are ancient at this point.

> [4] Is a full uninstall enough, or should I reinstall
> RH itself?

The latter is more complete, but if you don't see any more httpd.conf
files or Apache:: modules, you have probably cleaned things close
enough.

- Perrin

The uploaded file

     Apache-AuthenNIS-0.11.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthenNIS-0.11.tar.gz
   size: 4095 bytes
    md5: cac172a46c5b05034842fad5eed6b9be

Apache::AuthenNIS - mod_perl NIS Authentication module has been ported to work
with both versions of modperl.

thanks,
speeves
cws

Hi there,

On Fri, 1 Aug 2003, Tofu Optimist wrote:

> Rather than /usr/src, I put in /home/aprk

That's fine.  But in future, tell us what you did, not some fiction... :)

> Yes, you are correct.  make && make test as non-root,
> then install as root.  (Odd, isn't it, the docs at
>
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl\
_Installation
> don't make this explicit?)

Yes, I always think that, but many of the Open Source packages neglect
to mention this point every time it might be mentioned.  I think authors
expect it to be either very obvious or else perhaps unnecessary - some
operating systems don't have a Unix-like permisisons system.

> > Did you build your own Perl?
>
> Yes, 5.8.0

Good.  You might want to try 5.8.1 soon, but I don't think that's a
problem here.

> > Have you cleaned up any old Apaches and mod_perls?
>
> No.  There are probably hordes of perls and hpptds and mod_perls
> running amok on the box throwing wild parties; I don't know.

Argh.  The Apache2/modperl2 that comes with RH9 is junk.  Get rid of
it all.  Use 'ps' to see what processes you have running and stop any
httpd processes that you don't think you started.  RH will start an
Apache when it boots if you let it, I wish they wouldn't do that.
Read 'man chkconfig'.  Go into /etc/rc.d and look at the startup
scripts.  Use chkconfig to prevent Apache being started at boot so
you can start it manually when you've built it.  When you're happy
that it's all as you wnt it, you might want to use chkconfig to set
it up to start at boot again.

> I think my next step should be to start over fresh.
> Again.

:)

> [1] How do I find *everything* on the box related to
> perl / apache / mod_perl, both 1 and 2, both the RH
> install and from my own ftp / tar / make fumblings?
> [2] How do I uninstall everything from [1], so I can
> start fresh?

Well RH should let you uninstall packages with rpm, but I don't use
rpm and I tend to avoid RedHat so I don't know exactly how you'd do
it.  My preference would be to look in /usr/local/ and /var/lib to see
if there are any apache things such as /usr/local/apache, and if so go
in there as root and rm -rf the entire apache directory.  That will
perhaps throw away config files etc. you've been working on, you might
want to make backups.  When you've done that you might want to use
slocate to build a database of filenames on your filesystem, then use
it to search for any httpd or apachectl files that escaped.  If so
there'll probably be truckloads of files in there with them.  Nukem.
The source trees in your home directory don't matter.  Nuke them too.
You won't need to do anything about Perl on your system if you really
did compile it from source yourself.

> [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP
> is using.  And I think I'd prefer to use RH rpm to install them, as
> again, that is what my ISP did.  (Want my dev box to match the
> outside box as much as possible).  This newsgroup keeps mentioning
> "build from sources," will I be going astray trying the rpm route?

I hate RPMs.  For Apache2/modperl2 you would be better off going to
the CVS sources unless you can get hold of a very recent RPM, things
are changing really fast in the mod_perl version 2 codebase.  True, it
could be important for your dev box to match your prod box, but when
you figure out what's going on it will probably matter less - until
you start doing really fancy stuff, when it will start to matter again.

> [4] Is a full uninstall enough, or should I reinstall RH itself?

No, don't reinstall the entire OS.  Get used to what your system feels
like and eventually you'll know what to leave alone and what to change.

> mysteries to a newcomer.

FWIW you sound like you're picking it up quickly.

73,
Ged.

The uploaded file

     Apache-AuthzNIS-0.11.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthzNIS-0.11.tar.gz
   size: 4305 bytes
    md5: 37bbbdc320c6bba7318d817e854bc8e1

Apache::AuthzNIS - mod_perl NIS Group Authorization module has been ported to
work with both versions of modperl.

thanks,
speeves

> Sorry about this - I had a hard disc crash, and am just in
> the process of restoring things. Computers are getting too
> smart - they know when you're vulnerable, and will act
> accordingly ... Hopefully it'll be ready in a day.

Great job Randy! Got mod_perl installed, so I can now start bashing my code
to see how much punishment it needs before agreeing to run on it! :-)

Thanks!

J-S

On Fri, 2003-08-01 at 11:10, Roger Davenport wrote:
> I've been working with Apache::Reload and Registry and have been
> unable to get any cache flushing to work.  (I've added debug messages
> in Registry to show cache use or reloading).

Can you tell us what you are trying to reload and how you know it is
isn't happening?  Keep in mind, Apache::Reload has nothing to do with
reloading Registry scripts.  That reloading is handled entirely within
Registry itself.

- Perrin

Hello all,

I am using CGI::App 3.1, Apache 1.3.27 and mod_perl 1.28

Here's the problem. I'm trying to set a cookie (using CGI's cookie method and
C::A's header_props method). When the site was running non mod_perl there was
no problem. The cookie was set. When running under mod_perl the cookie is no
where to be seen. If I understand this correctly, then C::A uses CGI to set
the cookie and CGI should set it correctly if I'm running under mod_perl right?
I've seen a lot on forums to use Apache::Cookie, but how do I do that within
C::A?

Any ideas would be appreciated.
Thanks

Michael Peters
Venzia

On Fri, 2003-08-01 at 13:04, petersm wrote:
> When running under mod_perl the cookie is no
> where to be seen.

Do some debugging.  Look at the traffic going back and forth.  Test it
with GET or lynx.  See if the cookie header is being sent.

> If I understand this correctly, then C::A uses CGI to set
> the cookie and CGI should set it correctly if I'm running under mod_perl
right?

Right, although I don't think C::A knows or cares at all about cookies.
This is just between you and CGI.pm.

> I've seen a lot on forums to use Apache::Cookie, but how do I do that within
C::A?

You don't need to use Apache::Cookie, but if you want to you should be
able to use it in the normal documented way.  C::A should not have any
bearing on this.

- Perrin

Hello all,
I am working on a large modperl app, and one of the features of this is a
plugin system that allows others to write and install modules. Everything is
good as far as this goes, but the problem is updateing/deleting modules. It
seems as though the code is cached until an apache restart (i.e code changes
don't take effect, version numbers don't change). Is there a way to flush
the INC hash of all the children programmatically, without a restart? I have
looked at Apache::Reload and Apache::StatINC and tried to replicate the
code, but it doesn't seem to be working.

Thanks,
Scott

On Fri, 2003-08-01 at 13:42, Scott wrote:
> I have
> looked at Apache::Reload and Apache::StatINC

And what was wrong with them?  You should know that there is no perfect
way to reload a Perl module.  It just isn't a feature of the language.
Those two modules come as close as you can get without actually starting
a new interpreter, but it is still possible for some code (especially
code using closures) to interact badly with them.

- Perrin

[ Please keep it on the list... ]

On Fri, 2003-08-01 at 14:06, petersm wrote:
> Perrin Harkins <perrin@...> wrote
> > Do some debugging.  Look at the traffic going back and forth.  Test
> > it with GET or lynx.  See if the cookie header is being sent.
>
> Thanks for the suggestion. I used wget and tried it with the mod_perl stuff in
> the config and without. Without, wget gave me the header with the cookie.
> With, wget did not have a cookie in the header. Both returned the correct
HTML.
> Maybe some a glance at my config file could help. So here's the relavant
> portion. Thanks...
>
>
> PerlModule Apache::StatINC
> <Location /operations/projects/menagerie>
>     AddHandler perl-script .cgi
>     PerlHandler Apache::Registry
>     PerlSendHeader On
>     allow from all
>     PerlInitHandler Apache::StatINC
>     PerlSetVar StatINCDebug On
>     PerlSetEnv PERL5LIB /development/operations/projects/
> </Location>

That looks okay to me.  Maybe it's something about the way you've
structured your code.  Try reducing it down to a small snippet that you
can post.  You may also want to ask on the CGI::Application list.

- Perrin

Thanks Ged.

> [4] Is a full uninstall enough, or should I
> reinstall RH itself?
>
> No, don't reinstall the entire OS.  Get used to what
> your system feels
> like and eventually you'll know what to leave alone
> and what to change.

Well, I opted to reinstall everything, starting with a
fresh RH9.

Then I removed all the relevant RH9 RPMS:

root@SAM root]# rpm -e mod_ssl
[root@SAM root]# rpm -e mod_python
[root@SAM root]# rpm -e pho
[root@SAM root]# rpm -e php-ldap
[root@SAM root]# rpm -e php-imap
[root@SAM root]# rpm -e php
[root@SAM root]# rpm -e redhat-config-httpd
[root@SAM root]# rpm -e webalizer
[root@SAM root]# rpm -e mod_perl
[root@SAM root]# rpm -e httpd

(I had to take out mod_ssl, mod_python, etc so as to
free up dependencies.)

MY QUESTION:

Now I want to remove perl, too:

[root@SAM root]# rpm -e perl
error: Failed dependencies:
         perl is needed by (installed) logwatch-4.3.1-2
         perl is needed by (installed) w3m-0.3.2.2-5
         perl >= 0:5.002 is needed by (installed)
perl-Filter-1.29-3
         perl >= 0:5.00503 is needed by (installed)
perl-DateManip-5.40-30
         perl >= 0:5.000 is needed by (installed)
perl-DateManip-5.40-30
         perl >= 0:5.00503 is needed by (installed)
perl-HTML-Tagset-3.03-28
         perl >= 1:5 is needed by (installed)
perl-HTML-Tagset-3.03-28
         perl >= 5.6.0 is needed by (installed)
perl-HTML-Parser-3.26-17
         perl >= 0:5.004 is needed by (installed)
perl-HTML-Parser-3.26-17
         perl >= 0:5.00503 is needed by (installed)
perl-Parse-Yapp-1.05-30
         perl >= 0:5.004 is needed by (installed)
perl-Parse-Yapp-1.05-30
         perl >= 0:5.00503 is needed by (installed)
perl-URI-1.21-7
         perl >= 0:5.00503 is needed by (installed)
perl-libwww-perl-5.65-6
         perl >= 0:5.002 is needed by (installed)
perl-libwww-perl-5.65-6
         perl >= 0:5.004 is needed by (installed)
perl-libwww-perl-5.65-6
         perl >= 0:5.005 is needed by (installed)
perl-libwww-perl-5.65-6
         perl >= 2:5.8.0 is needed by (installed)
perl-XML-Parser-2.31-15
         perl >= 0:5.004 is needed by (installed)
perl-XML-Parser-2.31-15
         perl >= 5.6.0 is needed by (installed)
perl-libxml-perl-0.07-28
  perl >= 0:5.005 is needed by (installed)
perl-libxml-perl-0.07-28
         perl >= 5.6.0 is needed by (installed)
perl-XML-Dumper-0.4-25
         perl >= 5.6.0 is needed by (installed)
perl-XML-Encoding-1.01-23
         perl >= 0:5.005 is needed by (installed)
perl-XML-Encoding-1.01-23
         perl >= 0:5.00503 is needed by (installed)
perl-libxml-enno-1.02-29
         perl >= 5.6.0 is needed by (installed)
perl-XML-Grove-0.46alpha-25
         perl >= 0:5.005 is needed by (installed)
perl-XML-Grove-0.46alpha-25
         perl >= 0:5.004 is needed by (installed)
perl-XML-Twig-3.09-3
         perl >= 5.6.1 is needed by (installed)
foomatic-2.0.2-15
         perl is needed by (installed)
redhat-config-printer-0.6.47-1
         perl >= 1:5 is needed by (installed)
emacs-21.2-33
         perl is needed by (installed)
libgnomeprint22-2.2.1.1-3
         perl is needed by (installed)
docbook-dtds-1.0-17
         perl is needed by (installed)
libgnomeprint-1.116.0-6
         perl is needed by (installed)
desktop-printing-0.1.10-6
         perl >= 1:5 is needed by (installed)
xscreensaver-4.07-2
         perl is needed by (installed) autoconf-2.57-3
         perl >= 0:5.000 is needed by (installed)
autoconf-2.57-3
         perl >= 0:5.005_03 is needed by (installed)
autoconf-2.57-3
         perl is needed by (installed)
automake14-1.4p6-5.1
         perl is needed by (installed) automake15-1.5-6
         perl >= 0:5.005 is needed by (installed)
automake15-1.5-6


Now, in this forum I heard the importance of building
perl with the same compiler that you use for httpd and
mod_perl.

Am I going to have problems following the MP 2.0
install instructions

http://perl.apache.org/docs/2.0/user/install/install.html

if I don't nuke the current perl first?

Thanks.

And this time I'll restrict my reading to the 2.0
install docs, rather than dipping back into the 1.0
docs in the middle of 2.0 install.  (Doh!)

Thanks for advice on this --

A






> > > Did you build your own Perl?
> > Yes, 5.8.0
> Good.  You might want to try 5.8.1 soon, but I don't
> think that's a
> problem here.
>
> > > Have you cleaned up any old Apaches and
> mod_perls?
> >
> > No.  There are probably hordes of perls and hpptds
> and mod_perls
> > running amok on the box throwing wild parties; I
> don't know.
>
> Argh.  The Apache2/modperl2 that comes with RH9 is
> junk.  Get rid of
> it all.  Use 'ps' to see what processes you have
> running and stop any
> httpd processes that you don't think you started.
> RH will start an
> Apache when it boots if you let it, I wish they
> wouldn't do that.
> Read 'man chkconfig'.  Go into /etc/rc.d and look at
> the startup
> scripts.  Use chkconfig to prevent Apache being
> started at boot so
> you can start it manually when you've built it.
> When you're happy
> that it's all as you wnt it, you might want to use
> chkconfig to set
> it up to start at boot again.
>
> > I think my next step should be to start over
> fresh.
> > Again.
>
> :)
>
> > [1] How do I find *everything* on the box related
> to
> > perl / apache / mod_perl, both 1 and 2, both the
> RH
> > install and from my own ftp / tar / make
> fumblings?
> > [2] How do I uninstall everything from [1], so I
> can
> > start fresh?
>
> Well RH should let you uninstall packages with rpm,
> but I don't use
> rpm and I tend to avoid RedHat so I don't know
> exactly how you'd do
> it.  My preference would be to look in /usr/local/
> and /var/lib to see
> if there are any apache things such as
> /usr/local/apache, and if so go
> in there as root and rm -rf the entire apache
> directory.  That will
> perhaps throw away config files etc. you've been
> working on, you might
> want to make backups.  When you've done that you
> might want to use
> slocate to build a database of filenames on your
> filesystem, then use
> it to search for any httpd or apachectl files that
> escaped.  If so
> there'll probably be truckloads of files in there
> with them.  Nukem.
> The source trees in your home directory don't
> matter.  Nuke them too.
> You won't need to do anything about Perl on your
> system if you really
> did compile it from source yourself.
>
> > [3] I'd prefer to use modperl 2 and apache 2, as
> that is what my ISP
> > is using.  And I think I'd prefer to use RH rpm to
> install them, as
> > again, that is what my ISP did.  (Want my dev box
> to match the
> > outside box as much as possible).  This newsgroup
> keeps mentioning
> > "build from sources," will I be going astray
> trying the rpm route?
>
> I hate RPMs.  For Apache2/modperl2 you would be
> better off going to
> the CVS sources unless you can get hold of a very
> recent RPM, things
> are changing really fast in the mod_perl version 2
> codebase.  True, it
> could be important for your dev box to match your
> prod box, but when
> you figure out what's going on it will probably
> matter less - until
> you start doing really fancy stuff, when it will
> start to matter again.
>
>
> > mysteries to a newcomer.
>
> FWIW you sound like you're picking it up quickly.
>
> 73,
> Ged.
>


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

On Fri, 2003-08-01 at 16:24, Tofu Optimist wrote:
> Am I going to have problems following the MP 2.0
> install instructions
>
> http://perl.apache.org/docs/2.0/user/install/install.html
>
> if I don't nuke the current perl first?

No, you should be fine.  However, I have also simply installed a new
perl on top of the one shipped by RH with no problems.  (I did this
because I wanted to use 5.6.1 rather than 5.8.0.)  You will be blowing
the RPM system by doing that, so it's not an advisable way to handle a
large cluster of machines, but it works fine if you just need to get a
quick dev environment bootstrapped.

- Perrin