RE: mod_perl always segfault on thread creation

I'm confused. from Dayam Ivano's reply in this thread, he shows perl *and* mod_perl builds dynalically linked to libperl.so.

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

That's exactly how I configure the mod_perl

perl Makefile.PL MP_APXS=/usr/sbin/apxs

The static one would require passing another option that I didn't even aware of.


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