At 12:23 PM 4/30/2004, Stas Bekman wrote:
Thanks Bill!
Do other Apache modules work as DSO on those platforms?
Since my builds are 32 bit, I can't tell you for certain, but I'd expect the httpd/apr folks would have heard by now of a problem.
Difference, is that most modules are not nearly as complex, nor require the startup constructor and destructor logic that mod_perl needs.
Right.
Oh, silly observation - but if the whole thing is fluxored, I wonder if modperl, or perl is compiled against some additional 32-bit libs.
Olivier has posted his 'perl -V', it's hard to tell for sure, but take a look at the 'Compiler' section below:
*** /opt/perl583/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=hpux, osvers=11.11, archname=PA-RISC2.0-thread-multi-LP64
uname='hp-ux loire b.11.11 u 9000800 1756907651 unlimited-user license '
config_args='-A prepend:libswanted=cl pthread -Accflags=+Z -Dusethreads -Duse64bitall -Duse64bitint -Dprefix=/opt/perl583'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef 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_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 +Z -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ',
optimize='+O2 +Onolimit',
cppflags='-Aa -D__STDC_EXT__ -D_HPUX_SOURCE -D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 +Z -I/usr/local/include'
ccversion='B.11.11.04', gccversion='', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
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='/usr/bin/ld', ldflags =' +DD64 -L/usr/local/lib -L/lib/pa20_64'
libpth=/usr/local/lib /lib/pa20_64 /lib /usr/lib /usr/ccs/lib
libs=-lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc
perllibs=-lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc
libc=/lib/pa20_64/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
cccdlflags='+Z', lddlflags='-b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64'
HP is migrating folks away from shl_xxx api to the dl_xxx api, but they have done a lousy job on consistency in hpux-11/32 bit. With their 11i 64 bit support they have been much more consistent, and practically scream for users to move to dl_xxx. This is why I wanted Olivier to try backing out that patch that picks up shl_ over dl_.
Well, I hope Olivier will be able to do that testing.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
