FAQ
hi,

This is totally frustrating. My mod_perl script always causes segmentation fault when it tries to create a thread. I searched the Web and this forum, but there is still no definitive answers. My perl and mod_perl are of pretty recent versions and I check for the inclusion of useithreads config. I wrote a simple script to prove it:

use CGI;
use threads;
use Config;
use mod_perl;

our $LOGGER;
BEGIN {
$LOGGER = Apache2::ServerUtil->server->log;
$LOGGER->error("testhread starting (CGI version ".CGI->version.")");
}

my $q = CGI->new;
my $check = defined $Config{useithreads};
$LOGGER->error("useithread? $check");
my $v = mod_perl->VERSION;
$LOGGER->error("version $v");

my $thr = threads->create(sub { }); # comment out these two lines will work
$thr->join(); # already crashed at the line above

$q->header(-status => '200 OK');

It produces logs

Aug 20 13:07:50 (4216) [error] testhread starting (CGI version 3.51)
Aug 20 13:07:50 (4216) [error] useithread? 1
Aug 20 13:07:50 (4216) [error] version 2.000004
Aug 20 13:07:51 (4159) [notice] child pid 4216 exit signal Segmentation fault (11)

Any way I can solve this?

Thanks!

(Perl -V)
Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

Platform:
osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi
uname='linux hs20-bc2-5.build.redhat.com 2.6.18-274.3.1.el5 #1 smp fri aug 26 18:49:02 edt 2011 x86_64 x86_64 x86_64 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.4.5 20110214 (Red Hat 4.4.5-6)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -fstack-protector'
libpth=/usr/local/lib64 /lib64 /usr/lib64
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.12'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_REENTRANT_API
Built under linux
Compiled at Oct 4 2011 10:53:24
@INC:
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

Search Discussions

  • Rommel Sharma at Aug 21, 2012 at 6:41 am
    Hi,

    You could try some options for configuring Perl given here:
    http://perl.apache.org/docs/2.0/user/install/install.pod.orig

    specially:
    % CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC

    Before doing a make.

    Thanks,
    Rommel.


    From: hack bear
    Sent: Tuesday, August 21, 2012 2:06 AM
    To: modperl@perl.apache.org
    Subject: mod_perl always segfault on thread creation

    hi,

    This is totally frustrating. My mod_perl script always causes segmentation fault when it tries to create a thread. I searched the Web and this forum, but there is still no definitive answers. My perl and mod_perl are of pretty recent versions and I check for the inclusion of useithreads config. I wrote a simple script to prove it:

    use CGI;
    use threads;
    use Config;
    use mod_perl;

    our $LOGGER;
    BEGIN {
    $LOGGER = Apache2::ServerUtil->server->log;
    $LOGGER->error("testhread starting (CGI version ".CGI->version.")");
    }

    my $q = CGI->new;
    my $check = defined $Config{useithreads};
    $LOGGER->error("useithread? $check");
    my $v = mod_perl->VERSION;
    $LOGGER->error("version $v");

    my $thr = threads->create(sub { }); # comment out these two lines will work
    $thr->join(); # already crashed at the line above

    $q->header(-status => '200 OK');

    It produces logs

    Aug 20 13:07:50 (4216) [error] testhread starting (CGI version 3.51)
    Aug 20 13:07:50 (4216) [error] useithread? 1
    Aug 20 13:07:50 (4216) [error] version 2.000004
    Aug 20 13:07:51 (4159) [notice] child pid 4216 exit signal Segmentation fault (11)

    Any way I can solve this?

    Thanks!

    (Perl -V)
    Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

    Platform:
    osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi
    uname='linux hs20-bc2-5.build.redhat.com 2.6.18-274.3.1.el5 #1 smp fri aug 26 18:49:02 edt 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.5 20110214 (Red Hat 4.4.5-6)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
    Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12'
    Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
    Characteristics of this binary (from libperl):
    Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
    PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
    USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
    USE_PERLIO USE_REENTRANT_API
    Built under linux
    Compiled at Oct 4 2011 10:53:24
    @INC:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5
  • Hack bear at Aug 22, 2012 at 11:05 pm
    Thanks but the trick doesn't seem to help.

    First the instruction seems wrong. With it, the resulting perl executable does not even have useithreads defined.

    Then I try

    CFLAGS='-m64 -mtune=nocona' ./Configure -Dinstallusrbinperl -Dusethreads -Duseithreads -Dprefix=/usr -des -A ccflags="-fPIC -m64 -mtune=nocona "

    Now I get a perl with useithread and -mtune=nocona (versus -mtune=generic)

    # perl -V
    Summary of my perl5 (revision 5 version 16 subversion 1) configuration:

    Platform:
    osname=linux, osvers=2.6.32-131.12.1.el6.x86_64, archname=x86_64-linux-thread-multi
    uname='linux alcatraz6 2.6.32-131.12.1.el6.x86_64 #1 smp wed sep 21 08:12:51 pdt 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dinstallusrbinperl -Dusethreads -Duseithreads -Dprefix=/usr -des -A ccflags=-fPIC -m64 -mtune=nocona '
    hint=previous, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fPIC -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -m64 -mtune=nocona',

    Then I install the perl build, build mod_perl and install. Verify I'm using the new versions in apache. But still the script produces segfault consistently.

    Did people ever get threads to work in mod_perl/apache/redhat enterprise linux 6? May someone send the "perl -V" output. This basic feature should work out of box on any environment.


    From: rsharma51@sapient.com
    To: hackingbear@hotmail.com; modperl@perl.apache.org
    Subject: RE: mod_perl always segfault on thread creation
    Date: Tue, 21 Aug 2012 06:41:09 +0000









    Hi,

    You could try some options for configuring Perl given here:
    http://perl.apache.org/docs/2.0/user/install/install.pod.orig

    specially:
    % CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC

    Before doing a make.

    Thanks,
    Rommel.





    From: hack bear


    Sent: Tuesday, August 21, 2012 2:06 AM

    To: modperl@perl.apache.org

    Subject: mod_perl always segfault on thread creation




    hi,



    This is totally frustrating. My mod_perl script always causes segmentation fault when it tries to create a thread. I searched the Web and this forum, but there is still no definitive answers. My perl and mod_perl are of pretty recent versions and I check for
    the inclusion of useithreads config. I wrote a simple script to prove it:



    use CGI;

    use threads;

    use Config;

    use mod_perl;



    our $LOGGER;

    BEGIN {

    $LOGGER = Apache2::ServerUtil->server->log;

    $LOGGER->error("testhread starting (CGI version ".CGI->version.")");

    }



    my $q = CGI->new;

    my $check = defined $Config{useithreads};

    $LOGGER->error("useithread? $check");

    my $v = mod_perl->VERSION;

    $LOGGER->error("version $v");



    my $thr = threads->create(sub { }); # comment out these two lines will work

    $thr->join(); # already crashed at the line above



    $q->header(-status => '200 OK');



    It produces logs



    Aug 20 13:07:50 (4216) [error] testhread starting (CGI version 3.51)

    Aug 20 13:07:50 (4216) [error] useithread? 1

    Aug 20 13:07:50 (4216) [error] version 2.000004

    Aug 20 13:07:51 (4159) [notice] child pid 4216 exit signal Segmentation fault (11)



    Any way I can solve this?



    Thanks!



    (Perl -V)

    Summary of my perl5 (revision 5 version 10 subversion 1) configuration:



    Platform:

    osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi

    uname='linux hs20-bc2-5.build.redhat.com 2.6.18-274.3.1.el5 #1 smp fri aug 26 18:49:02 edt 2011 x86_64 x86_64 x86_64 gnulinux '

    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat,
    Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl
    -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
    -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin'

    hint=recommended, useposix=true, d_sigaction=define

    useithreads=define, usemultiplicity=define

    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef

    use64bitint=define, use64bitall=define, uselongdouble=undef

    usemymalloc=n, bincompat5005=undef

    Compiler:

    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',

    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',

    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'

    ccversion='', gccversion='4.4.5 20110214 (Red Hat 4.4.5-6)', gccosandvers=''

    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678

    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16

    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8

    alignbytes=8, prototype=define

    Linker and Libraries:

    ld='gcc', ldflags =' -fstack-protector'

    libpth=/usr/local/lib64 /lib64 /usr/lib64

    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc

    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc

    libc=, so=so, useshrplib=true, libperl=libperl.so

    gnulibc_version='2.12'

    Dynamic Linking:

    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'

    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

    Characteristics of this binary (from libperl):

    Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV

    PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL

    USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES

    USE_PERLIO USE_REENTRANT_API

    Built under linux

    Compiled at Oct 4 2011 10:53:24

    @INC:

    /usr/local/lib64/perl5

    /usr/local/share/perl5

    /usr/lib64/perl5/vendor_perl

    /usr/share/perl5/vendor_perl

    /usr/lib64/perl5

    /usr/share/perl5
  • Doug Hunt at Aug 22, 2012 at 11:11 pm
    Hi Rommel: Are you building statically or dynamically? I had a problem
    with segfaulting mod_perl, the solution for which eluded me for a long
    time. I had been doing a static apache/mod_perl build on CentOS 6.3
    (similar to RedHat Enterprise 6.3).

    I finally cured the problem by just doing a dynamic build instead. From
    what I can tell, static builds in my environment (x86_64, CentOS 6.3, perl
    5.16.1) are pretty well broken. The dynamic build went just fine.

    Just a thought...

    --Doug Hunt

    dhunt@ucar.edu
    Software Engineer
    UCAR - COSMIC, Tel. (303) 497-2611
    On Wed, 22 Aug 2012, hack bear wrote:

    Thanks but the trick doesn't seem to help.

    First the instruction seems wrong. With it, the resulting perl executable does not even have useithreads defined.

    Then I try

    CFLAGS='-m64 -mtune=nocona' ./Configure -Dinstallusrbinperl -Dusethreads -Duseithreads -Dprefix=/usr -des -A ccflags="-fPIC
    -m64 -mtune=nocona "

    Now I get a perl with useithread and -mtune=nocona (versus -mtune=generic)

    # perl -V
    Summary of my perl5 (revision 5 version 16 subversion 1) configuration:

    Platform:
    osname=linux, osvers=2.6.32-131.12.1.el6.x86_64, archname=x86_64-linux-thread-multi
    uname='linux alcatraz6 2.6.32-131.12.1.el6.x86_64 #1 smp wed sep 21 08:12:51 pdt 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dinstallusrbinperl -Dusethreads -Duseithreads -Dprefix=/usr -des -A ccflags=-fPIC -m64 -mtune=nocona '
    hint=previous, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fPIC -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
    -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -m64 -mtune=nocona',

    Then I install the perl build, build mod_perl and install. Verify I'm using the new versions in apache. But still the script
    produces segfault consistently.

    Did people ever get threads to work in mod_perl/apache/redhat enterprise linux 6? May someone send the "perl -V" output. This
    basic feature should work out of box on any environment.


    _______________________________________________________________________________________________________________________________
    From: rsharma51@sapient.com
    To: hackingbear@hotmail.com; modperl@perl.apache.org
    Subject: RE: mod_perl always segfault on thread creation
    Date: Tue, 21 Aug 2012 06:41:09 +0000

    Hi,



    You could try some options for configuring Perl given here:

    http://perl.apache.org/docs/2.0/user/install/install.pod.orig



    specially:

    % CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC



    Before doing a make.



    Thanks,

    Rommel.





    From: hack bear
    Sent: Tuesday, August 21, 2012 2:06 AM
    To: modperl@perl.apache.org
    Subject: mod_perl always segfault on thread creation



    hi,

    This is totally frustrating. My mod_perl script always causes segmentation fault when it tries to create a thread. I searched
    the Web and this forum, but there is still no definitive answers. My perl and mod_perl are of pretty recent versions and I
    check for the inclusion of useithreads config. I wrote a simple script to prove it:

    use CGI;
    use threads;
    use Config;
    use mod_perl;

    our $LOGGER;
    BEGIN {
    $LOGGER = Apache2::ServerUtil->server->log;
    $LOGGER->error("testhread starting (CGI version ".CGI->version.")");
    }

    my $q       = CGI->new;
    my $check = defined $Config{useithreads};
    $LOGGER->error("useithread? $check");
    my $v = mod_perl->VERSION;
    $LOGGER->error("version $v");

    my $thr = threads->create(sub { }); # comment out these two lines will work
    $thr->join(); # already crashed at the line above

    $q->header(-status => '200 OK');

    It produces logs

    Aug 20 13:07:50 (4216) [error] testhread starting (CGI version 3.51)
    Aug 20 13:07:50 (4216) [error] useithread? 1
    Aug 20 13:07:50 (4216) [error] version 2.000004
    Aug 20 13:07:51 (4159) [notice] child pid 4216 exit signal Segmentation fault (11)

    Any way I can solve this?

    Thanks!

    (Perl -V)
    Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

    Platform:
    osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi
    uname='linux hs20-bc2-5.build.redhat.com 2.6.18-274.3.1.el5 #1 smp fri aug 26 18:49:02 edt 2011 x86_64 x86_64 x86_64
    gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
    --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost
    -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5
    -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5
    -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0
    -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads
    -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
    -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto
    -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto
    -Dscriptdir=/usr/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
    -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
    -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.5 20110214 (Red Hat 4.4.5-6)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
    Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12'
    Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
    --param=ssp-buffer-size=4 -m64 -mtune=generic'
    Characteristics of this binary (from libperl):
    Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
    PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
    USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
    USE_PERLIO USE_REENTRANT_API
    Built under linux
    Compiled at Oct  4 2011 10:53:24
    @INC:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5

  • Hack bear at Aug 22, 2012 at 11:17 pm
    I'm doing a dynamic build (the default setting I believe.) here are the ldd results (that's how we can tell, right?)

    # 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 /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)

    Date: Wed, 22 Aug 2012 17:11:32 -0600
    From: dhunt@ucar.edu
    To: hackingbear@hotmail.com
    CC: modperl@perl.apache.org
    Subject: RE: mod_perl always segfault on thread creation

    Hi Rommel: Are you building statically or dynamically? I had a problem
    with segfaulting mod_perl, the solution for which eluded me for a long
    time. I had been doing a static apache/mod_perl build on CentOS 6.3
    (similar to RedHat Enterprise 6.3).

    I finally cured the problem by just doing a dynamic build instead. From
    what I can tell, static builds in my environment (x86_64, CentOS 6.3, perl
    5.16.1) are pretty well broken. The dynamic build went just fine.

    Just a thought...

    --Doug Hunt

    dhunt@ucar.edu
    Software Engineer
    UCAR - COSMIC, Tel. (303) 497-2611
    On Wed, 22 Aug 2012, hack bear wrote:

    Thanks but the trick doesn't seem to help.

    First the instruction seems wrong. With it, the resulting perl executable does not even have useithreads defined.

    Then I try

    CFLAGS='-m64 -mtune=nocona' ./Configure -Dinstallusrbinperl -Dusethreads -Duseithreads -Dprefix=/usr -des -A ccflags="-fPIC
    -m64 -mtune=nocona "

    Now I get a perl with useithread and -mtune=nocona (versus -mtune=generic)

    # perl -V
    Summary of my perl5 (revision 5 version 16 subversion 1) configuration:

    Platform:
    osname=linux, osvers=2.6.32-131.12.1.el6.x86_64, archname=x86_64-linux-thread-multi
    uname='linux alcatraz6 2.6.32-131.12.1.el6.x86_64 #1 smp wed sep 21 08:12:51 pdt 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dinstallusrbinperl -Dusethreads -Duseithreads -Dprefix=/usr -des -A ccflags=-fPIC -m64 -mtune=nocona '
    hint=previous, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fPIC -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
    -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -m64 -mtune=nocona',

    Then I install the perl build, build mod_perl and install. Verify I'm using the new versions in apache. But still the script
    produces segfault consistently.

    Did people ever get threads to work in mod_perl/apache/redhat enterprise linux 6? May someone send the "perl -V" output. This
    basic feature should work out of box on any environment.


    _______________________________________________________________________________________________________________________________
    From: rsharma51@sapient.com
    To: hackingbear@hotmail.com; modperl@perl.apache.org
    Subject: RE: mod_perl always segfault on thread creation
    Date: Tue, 21 Aug 2012 06:41:09 +0000

    Hi,



    You could try some options for configuring Perl given here:

    http://perl.apache.org/docs/2.0/user/install/install.pod.orig



    specially:

    % CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC



    Before doing a make.



    Thanks,

    Rommel.





    From: hack bear
    Sent: Tuesday, August 21, 2012 2:06 AM
    To: modperl@perl.apache.org
    Subject: mod_perl always segfault on thread creation



    hi,

    This is totally frustrating. My mod_perl script always causes segmentation fault when it tries to create a thread. I searched
    the Web and this forum, but there is still no definitive answers. My perl and mod_perl are of pretty recent versions and I
    check for the inclusion of useithreads config. I wrote a simple script to prove it:

    use CGI;
    use threads;
    use Config;
    use mod_perl;

    our $LOGGER;
    BEGIN {
    $LOGGER = Apache2::ServerUtil->server->log;
    $LOGGER->error("testhread starting (CGI version ".CGI->version.")");
    }

    my $q = CGI->new;
    my $check = defined $Config{useithreads};
    $LOGGER->error("useithread? $check");
    my $v = mod_perl->VERSION;
    $LOGGER->error("version $v");

    my $thr = threads->create(sub { }); # comment out these two lines will work
    $thr->join(); # already crashed at the line above

    $q->header(-status => '200 OK');

    It produces logs

    Aug 20 13:07:50 (4216) [error] testhread starting (CGI version 3.51)
    Aug 20 13:07:50 (4216) [error] useithread? 1
    Aug 20 13:07:50 (4216) [error] version 2.000004
    Aug 20 13:07:51 (4159) [notice] child pid 4216 exit signal Segmentation fault (11)

    Any way I can solve this?

    Thanks!

    (Perl -V)
    Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

    Platform:
    osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi
    uname='linux hs20-bc2-5.build.redhat.com 2.6.18-274.3.1.el5 #1 smp fri aug 26 18:49:02 edt 2011 x86_64 x86_64 x86_64
    gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
    --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost
    -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5
    -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5
    -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0
    -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads
    -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
    -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto
    -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto
    -Dscriptdir=/usr/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
    -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
    -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.5 20110214 (Red Hat 4.4.5-6)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
    Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12'
    Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
    --param=ssp-buffer-size=4 -m64 -mtune=generic'
    Characteristics of this binary (from libperl):
    Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
    PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
    USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
    USE_PERLIO USE_REENTRANT_API
    Built under linux
    Compiled at Oct 4 2011 10:53:24
    @INC:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5

  • Damyan Ivanov at Aug 23, 2012 at 6:18 am
    -=| 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
  • Hack bear at Aug 23, 2012 at 11:39 pm
    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: dmn@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
  • Doug Hunt at Aug 24, 2012 at 4:36 pm
    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

    dhunt@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: dmn@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
  • Hack bear at Aug 24, 2012 at 5:30 pm
    I'm confused. from Dayam Ivano's reply in this thread, he shows perl *and* mod_perl builds dynalically linked to libperl.so.
    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

    dhunt@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: dmn@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
  • Doug Hunt at Aug 24, 2012 at 6:54 pm
    dhunt@ucar.edu
    Software Engineer
    UCAR - COSMIC, Tel. (303) 497-2611
    On Fri, 24 Aug 2012, hack bear wrote:


    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.
    OK, so it sounds like you are doing a dynamic build of mod_perl. Really
    the only wisdom I have to offer here is *not* to do a static build, but it
    seems you are already not doing that.

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

    dhunt@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: dmn@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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodperl @
categoriesmodperl, perl
postedAug 20, '12 at 8:36p
activeAug 24, '12 at 6:54p
posts10
users4
websiteperl.apache.org

People

Translate

site design / logo © 2021 Grokbase