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.
>
>
