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
dh...@ucar.edu
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: d...@debian.org
> To: modperl@perl.apache.org
> 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
