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