OK, until I can decide whether to take a chance on FreeBSD-current
or to convince my employers who were so enamored of FreeBSD that
we should rebuild the server with Linux, I'm going prefork.
It still doesn't work precisely as it should though. I decided
to go with the cvs builds of apache and mod_perl. I have to
confess that the installation instructions seem strange (both for
CVS and non-CVS). You have to build and install Apache in order
to get the include files to build mod_perl. Then after doing
a make for mod_perl you are supposed to go back to Apache and
configure, make, make-install -- even though the mod_perl make
touched nothing in the Apache tree! I assume after all of this
you do make install on both Apache and mod_perl although the
doc doesn't say so.
Even after all of that I *still* get the Perl_Tstack_sp_ptr
error! Putting in the explicit LoadFile for libperl.so gets
rid of that problem, only to create another:
Cannot load /usr/lib/perl5/5.6.1/i386-freebsd-thread-multi/CORE/libperl.so
into server: /usr/lib/perl5/5.6.1/i386-freebsd-thread-multi/CORE/libperl.so:
Undefined symbol "pthread_getspecific"
Presumably this is because the Perl I used had thread support.
My workaround is to edit apachectl to preload libc_r.so:
start|stop|restart|graceful)
LD_PRELOAD=libc_r.so $HTTPD -k $ARGV
ERROR=$?
;;
startssl|sslstart|start-SSL)
LD_PRELOAD=libc_r.so $HTTPD -k start -DSSL
ERROR=$?
and finally everything appears to be working.
I suppose I could have done --enable-threads in Apache
with --with-mpm=prefork and it might have worked. Is
that considered kosher? Anyway this seems good enough
for now.
-P
> -----Original Message-----
> From: Paul G. Weiss
> Sent: Tuesday, June 11, 2002 1:22 PM
> To: 'Doug MacEachern'
> Cc: [EMAIL PROTECTED]
> Subject: RE: Perl_Tstack_sp_ptr
>
>
> I suspect that pre-fork would work too, but I'm desparately
> trying to get threads working.
>
> Here is apr.h
>
> [/usr/local/apache2/htdocs/perl]# grep -i thread
> /usr/local/apache2/include/apr.h
> #define APR_HAVE_PTHREAD_H 1
> #define APR_USE_PROC_PTHREAD_SERIALIZE 0
> #define APR_USE_PTHREAD_SERIALIZE 1
> #define APR_HAS_PROC_PTHREAD_SERIALIZE 0
> #define APR_HAS_THREADS 1
> #define APR_HAS_XTHREAD_FILES 0
> #define APR_THREAD_FUNC
> /* Does the proc mutex lock threads too */
>
> One more odd thing to report: I've noticed that I have both
> libc.so and libc_r.so in the mix. That can't be good, can it?
>
> Here is why I think so:
>
> INSTALLATION
> The current FreeBSD POSIX thread implementation is built
> in the library
> libc_r which contains both thread-safe libc functions
> and the thread
> functions. This library replaces libc for threaded applications.
>
> By default, libc_r is built as part of a 'make world'.
> To disable the
> build of libc_r you must supply the '-DNOLIBC_R' option
> to make(1).
>
> A FreeBSD specific option has been added to gcc to make
> linking threaded
> processes simple. gcc -pthread links a threaded process
> against libc_r
> instead of libc.
>
> -P
>
> [/usr/local/apache2/htdocs/perl]# LD_TRACE_LOADED_OBJECTS=1 \
> /usr/local/apache2/bin/httpd
> libaprutil.so.0 =>
> /usr/local/apache2/lib/libaprutil.so.0 (0x280a9000)
> libapr.so.0 => /usr/local/apache2/lib/libapr.so.0 (0x280b9000)
> libm.so.2 => /usr/lib/libm.so.2 (0x280d4000)
> libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280f0000)
> libssl.so.3 => /usr/lib/libssl.so.3 (0x28109000)
> libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x28136000)
> libexpat.so.1 => /usr/local/apache2/lib/libexpat.so.1
> (0x281ea000)
> libc_r.so.4 => /usr/lib/libc_r.so.4 (0x28206000)
> libc.so.4 => /usr/lib/libc.so.4 (0x282bb000)
>
>
> [/usr/local/apache2/htdocs/perl]# readelf -dD
> /usr/local/apache2/lib/libapr.so.0
>
> Dynamic segment at offset 0x1941c contains 17 entries:
> Tag Type Name/Value
> 0x00000001 (NEEDED) Shared library: [libc.so.4]
> 0x0000000e (SONAME) Library soname: [libapr.so.0]
> 0x0000000c (INIT) 0x5f08
> 0x0000000d (FINI) 0x18164
> 0x00000004 (HASH) 0x94
> 0x00000005 (STRTAB) 0x3494
> 0x00000006 (SYMTAB) 0x1184
> 0x0000000a (STRSZ) 8540 (bytes)
> 0x0000000b (SYMENT) 16 (bytes)
> 0x00000003 (PLTGOT) 0x19fc8
> 0x00000002 (PLTRELSZ) 2072 (bytes)
> 0x00000014 (PLTREL) REL
> 0x00000017 (JMPREL) 0x56f0
> 0x00000011 (REL) 0x55f0
> 0x00000012 (RELSZ) 256 (bytes)
> 0x00000013 (RELENT) 8 (bytes)
> 0x00000000 (NULL) 0x0
>
>
>
>
> > -----Original Message-----
> > From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 11, 2002 12:41 PM
> > To: Paul G. Weiss
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: Perl_Tstack_sp_ptr
> >
> >
> > On Tue, 11 Jun 2002, Doug MacEachern wrote:
> >
> > > could this be a version of freebsd with broken threads
> > support? i've
> > > heard many cases of that. chances are if you rebuild
> perl without
> > > -Dusethreads and apache with the prefork mpm, this problem
> > won't be there.
> >
> > this is likely the problem. i just compiled 2.0.36 on
> freebsd using
> > --with-mpm=worker, yet it compiled in the prefork mpm
> > instead. no idea
> > why it wouldn't just croak that worker isn't supported.
> >
> > in general, i think there will be trouble when perl is built with
> > -Dusethreads and httpd is not. check your include/apr.h:
> >
> > #define APR_HAS_THREADS 0
> >
> > 0 == trouble, 1 == ok.
> >
> >
>
