RE: mod_perl always segfault on thread creation

Hi hack bear:  When I speak of dynamic or static mod_perl builds, I mean 
the apache and mod_perl part, not the perl part.  All my apache/mod_perl 
builds link perl in statically, using libperl.a.

The two different recipes are found here:

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

and here:

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

I had been doing static builds (in which you unpack both apache and 
mod_perl distributions and compile them together) for years now, but this 
time I could not get it to work at all, even after some months of trying. 
It took me a couple of weeks and some ugly patches to the mod_perl source 
to get it to compile at all, but the resulting executable suffered from
random, flakey segfaults.

I finally switched to the dynamic build (in which you compile and install 
apache and then compile mod_perl separately) and this worked right away.

My opinion is that static builds in my environment (CentOS 6.3, 
x86_64, Apache 2.2.22, mod_perl 2.0.8 and perl 5.16.1) is simply broken.

The way to tell a static mod_perl/httpd build is that if you run:

$ nm /path/to/httpd | grep modperl

you will see many matches.  For a dynamic build, there will be no matches.

Regards,

   Doug Hunt

[email protected]
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611

On Thu, 23 Aug 2012, hack bear wrote:

> What exactly is the right way to build a shared-lib perl. I tried to follow the INSTALL instruction and many variations to get
> it work but still to no avail. For example I tried
> 
> # make clean
> # CFLAGS='-m64 -mtune=nocona' ./Configure -Dinstallusrbinperl -Dusethreads -Duseithreads -Duseshrplib -Dprefix=/usr -es -A
> ccflags="-fPIC -m64 -mtune=nocona " -A ldflags="-Duseshrplib" -A define:useshrplib -A define:usethreads -A define:useithreads
> -A define:installusrbinperl
> # make
> 
> Only the libperl.a is built
> # find . -name 'libperl*'
> ./libperl.a
> 
> And perl -V shows
>   ...
>   Linker and Libraries:
>     ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
>     libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
>     libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
>     perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
>     libc=, so=so, useshrplib=false, libperl=libperl.a
>     gnulibc_version='2.12'
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
>     cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'
> 
> And BTW is there any existing RPM for RHEL that is dynamic build already?
> 
> > Date: Thu, 23 Aug 2012 09:17:48 +0300
> > From: [email protected]
> > To: [email protected]
> > Subject: Re: mod_perl always segfault on thread creation
> >
> > -=| hack bear, 22.08.2012 16:16:33 -0700 |=-
> > >
> > > I'm doing a dynamic build (the default setting I believe.) here are the ldd results (that's how we can tell, right?)
> >
> > To me this seems like a static build. Yes, it links dynamicly to
> > system libraries, but the perl library is staticly linked. Compare
> > with ldd output on a stock Debian system below:
> > >
> > > # ldd /usr/bin/perl
> > > linux-vdso.so.1 => (0x00007ffff2dff000)
> > > libnsl.so.1 => /lib64/libnsl.so.1 (0x00000039c3c00000)
> > > libdl.so.2 => /lib64/libdl.so.2 (0x00000039bec00000)
> > > libm.so.6 => /lib64/libm.so.6 (0x00000039bfc00000)
> > > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000039c1800000)
> > > libutil.so.1 => /lib64/libutil.so.1 (0x00000039c4000000)
> > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039bf400000)
> > > libc.so.6 => /lib64/libc.so.6 (0x00000039bf000000)
> > > /lib64/ld-linux-x86-64.so.2 (0x00000039be800000)
> > > libfreebl3.so => /lib64/libfreebl3.so (0x00000039c2c00000)
> >
> > $ ldd /usr/bin/perl ~
> > linux-vdso.so.1 => (0x00007fff53dff000)
> > libperl.so.5.14 => /usr/lib/libperl.so.5.14 (0x00007f5e53c1f000)
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5e53a1b000)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5e53798000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5e5357c000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5e531f5000)
> > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f5e52fbd000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f5e53fca000)
> >
> > > # ldd /etc/httpd/modules/mod_perl.so
> > > linux-vdso.so.1 => (0x00007fff33fff000)
> > > libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fbe6ec80000)
> > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fbe6ea7c000)
> > > libm.so.6 => /lib64/libm.so.6 (0x00007fbe6e7f7000)
> > > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fbe6e5c0000)
> > > libutil.so.1 => /lib64/libutil.so.1 (0x00007fbe6e3bd000)
> > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbe6e19f000)
> > > libc.so.6 => /lib64/libc.so.6 (0x00007fbe6de0e000)
> > > /lib64/ld-linux-x86-64.so.2 (0x00000039be800000)
> > > libfreebl3.so => /lib64/libfreebl3.so (0x00007fbe6dbac000)
> >
> > $ ldd /usr/lib/apache2/modules/mod_perl.so ~
> > linux-vdso.so.1 => (0x00007fffe6bff000)
> > libperl.so.5.14 => /usr/lib/libperl.so.5.14 (0x00007f3bfba7e000)
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3bfb87a000)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3bfb5f7000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3bfb3db000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3bfb054000)
> > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f3bfae1c000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f3bfc065000)
> >
> > The difference is in the presence of libperl.so.5.14 in the output.
> >
> > Good luck,
> > dam
> 
>