I would like to report success, but that just isn't going to happen.
I've been installing from /usr/pkgsrc, trying different combinations of
installations, and I keep getting the same problem.  Whenever I run
apache with the -DPERL argument, I get a core dump.  This time (and the
last few) it has been in S_new_xpvav (), although it has failed in the
past in various other places (as I moved forward).

I think the thing that bothers me the most is that it doesn't deal 
with the error, it simply dumps core....

First - uname information:

NetBSD webserv02.neonramp.com 1.5.2 NetBSD 1.5.2 (NEONRAMP-RADIUS) #1: 
Sat Sep 29 11:18:54 PDT 2001
burgess@webserv02.neonramp.com:/usr/src/sys/arch/i386/compile/NEONRAMP-RADIUS
i386

I tried the new patch, and get the same basic problems that I've run 
into since Thursday:

webserv02# httpd -X -DPERL
Segmentation fault (core dumped)
webserv02# gdb -c httpd.core `which httpd`
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386--netbsd"...(no debugging symbols
found)...
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.elf_so...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libcrypt.so.0...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.so.12...(no debugging symbols
found)...done.
Reading symbols from /usr/pkg/lib/httpd/mod_perl.so...
(no debugging symbols found)...done.
Reading symbols from
/usr/pkg/lib/perl5/5.6.1/i386-netbsd/CORE/libperl.so...
(no debugging symbols found)...done.
Reading symbols from /usr/lib/libm387.so.0...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libm.so.0...(no debugging symbols
found)...done.
#0  0x481fdeb0 in S_new_xpvav ()
(gdb) bt
#0  0x481fdeb0 in S_new_xpvav ()
#1  0x481fe70d in Perl_sv_upgrade ()
#2  0x481f51c6 in Perl_newAV ()
#3  0x481b0156 in perl_construct ()
#4  0x4816a006 in perl_startup ()
#5  0x4816d778 in perl_cmd_handler_handlers ()
#6  0x806f20d in invoke_cmd ()
#7  0x806f563 in ap_handle_command ()
#8  0x806f5ac in ap_srm_command_loop ()
#9  0x8071cda in filesection ()
#10 0x806f345 in invoke_cmd ()
#11 0x806f563 in ap_handle_command ()
#12 0x806f5ac in ap_srm_command_loop ()
#13 0x806fa5a in ap_process_resource_config ()
#14 0x80700a8 in ap_read_config ()
#15 0x8076c32 in standalone_main ()
#16 0x80773cb in main ()
#17 0x804fc39 in ___start ()
(gdb) 

The results of a pkg_info -a yields the following:

digest-20010807     Message digest wrapper utility
apache-1.3.20       HTTP (Web) server
libtool-base-1.4.20010614nb2 Generic shared library support script (the
script itself)
db-2.7.7            Sleepycat Software's Berkeley DB version 2
pks-0.9.4           PGP Public Key Server
perl-5.6.1nb3       Practical Extraction and Report Language
libperl-5.6.1       Perl DynaLoader as a shared object
p5-BSD-Resource-1.10 BSD::Resource - Perl interface to BSD process
resources library
ap-perl-1.26        Module that embeds a Perl interpreter into Apache
ap-ssl-2.8.4        SSL/TLS protocols module for Apache
mit-pthreads-1.60b6 Chris Provenzano's (MIT) POSIX threads library

Here is the pertinent component of the apache.conf file:

# Note: The order in which modules are loaded is important.  Don't
change
# the order below without expert advice. 
# 
# Example:
# LoadModule foo_module lib/httpd/mod_foo.so

<IfDefine SSL>
LoadModule ssl_module lib/httpd/mod_ssl.so
AddModule mod_ssl.c
</IfDefine>

<IfDefine PERL>
  LoadModule perl_module lib/httpd/mod_perl.so
  AddModule mod_perl.c
  <Files ~ "\.pl$"> 
    PerlHandler         Apache::Registry
    PerlSendHeader      On
    SetHandler          perl-script
    Options             +ExecCGI 
  </Files>
</IfDefine>

#     

If I comment out the <Files>...</Files> section, I get a different
core dump:

#0  0x48204acf in Perl_newSVpvn ()
#1  0x481b000d in perl_construct ()
#2  0x4816a006 in perl_startup ()
#3  0x48169cf4 in perl_module_init ()
#4  0x807015f in ap_init_modules ()
#5  0x8076c88 in standalone_main ()
#6  0x80773cb in main ()
#7  0x804fc39 in ___start ()

One thing that I saw that I thought was odd was this:

webserv02# ls -ald /usr/bin/perl
lrwxrwxr-x  1 root  wheel  19 Oct 18  1997 /usr/bin/perl ->
/usr/local/bin/perl
webserv02# ls -ald /usr/local/bin/per*
-r-xr-xr-x  1 root  wheel  714592 Oct  1 17:53 /usr/local/bin/perl
-rwxr-xr-x  1 root  wheel   67749 Oct  1 17:45 /usr/local/bin/perl5.6.1
-rwxr-xr-x  1 root  wheel   35473 Oct  1 17:46 /usr/local/bin/perlbug
-rwxr-xr-x  1 root  wheel   16928 Oct  1 17:46 /usr/local/bin/perlcc
-rwxr-xr-x  1 root  wheel   22643 Oct  1 17:46 /usr/local/bin/perldoc

Should perl5.6.1 be 8 minutes younger than perl?  I tried relinking
/usr/bin/perl to the perl5.6.1 file, just for grins.  No difference.
 
Any help would be greatly appreciated.

P.S.  As soon as I get this working, I'm going to start on trying to
get MySQL InnoDB and BDB support working.  BDB compiles, but fails at
run-time, InnoDB doesn't even compile.

Dave

Todd Vierling wrote:
> 
> On Mon, 1 Oct 2001, Johnny Lam wrote:
> 
> : I've included below a patch to the perl package that causes perl modules
> : from CPAN to link directly against -lperl when built.  Combined with the
> : recent update of perl to add ${LOCALBASE}/lib to the rpath when creating
> : shared libraries/modules, these two changes make using mod_perl.so (ap-perl)
> : more painless.
> 
> FWIW (to get this out of my overflowing mailbox :), this looks great; please
> implement it.  This was my original intent with libperl.so ages ago, but I
> never managed to get to fixing it.
> 
> --
> -- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
> -- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/