Mailing List Archive

On Fri, 22 Dec 2000, Doug MacEachern wrote:

> the 5.6.0+ uselargefile flags: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> are still the source of many core dump reports. i just committed a patch
> to rip them out by default. mod_perl does not need them. but they can be
> turned back on with Makefile.PL PERL_USELARGEFILES=1
>
> i've tested with 5.6.0, 5.7.0-dev, USE_DSO=1, USE_APXS=1 and USE_APACI=1
> all on linux 2.x. it would be great to hear 'make test' reports with as
> many perls/os-es/options/etc. to ensure no breakage for 1.25 sometime next
> week. thanks.

System:
Linux Mandrake 7.2 / kernel 2.2.17-21mdk
Apache/1.3.14
mod_perl/1.24_02-dev (last minute checkout)
perl 5.6.0 (not patched)
Options:
perl Makefile.PL APACHE_SRC=../apache_1.3.14/src \
DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 PERL_TRACE=1

PASS!

_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

On Fri, Dec 22, 2000 at 06:11:51PM -0800, Doug MacEachern wrote:
> the 5.6.0+ uselargefile flags: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> are still the source of many core dump reports. i just committed a patch
> to rip them out by default. mod_perl does not need them. but they can be
> turned back on with Makefile.PL PERL_USELARGEFILES=1
>
> i've tested with 5.6.0, 5.7.0-dev, USE_DSO=1, USE_APXS=1 and USE_APACI=1
> all on linux 2.x. it would be great to hear 'make test' reports with as
> many perls/os-es/options/etc. to ensure no breakage for 1.25 sometime next
> week. thanks.

FreeBSD 3.4
perl 5.7.0
Apache 1.3.14
Latest mod_perl from cvs

perl Makefile.pl DO_HTTPD=1 APACHE_SRC=../apache_1.3.14 USE_APACI=1 EVERYTHING=1

passes fine.

--
Thomas Eibner

On Fri, Dec 22, 2000 at 06:11:51PM -0800, Doug MacEachern wrote:
> the 5.6.0+ uselargefile flags: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> are still the source of many core dump reports. i just committed a patch
> to rip them out by default. mod_perl does not need them. but they can be
> turned back on with Makefile.PL PERL_USELARGEFILES=1
>
> i've tested with 5.6.0, 5.7.0-dev, USE_DSO=1, USE_APXS=1 and USE_APACI=1
> all on linux 2.x. it would be great to hear 'make test' reports with as
> many perls/os-es/options/etc. to ensure no breakage for 1.25 sometime next
> week. thanks.

I assume that if Apache is built with LFS, we do need them (though I
think apxs will take care of that). What about if perl is - can we
really get away without not using LFS when perl is?

Debian's spent a couple of weeks tracking down the problems enabling
LFS in apache caused various modules (primarily PHP), and we've gotten
most of them now, so I'd hate to back down again.

Dan

/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/

On Fri, 22 Dec 2000, Doug MacEachern wrote:

> the 5.6.0+ uselargefile flags: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> are still the source of many core dump reports. i just committed a patch
> to rip them out by default. mod_perl does not need them. but they can be
> turned back on with Makefile.PL PERL_USELARGEFILES=1
>
> i've tested with 5.6.0, 5.7.0-dev, USE_DSO=1, USE_APXS=1 and USE_APACI=1
> all on linux 2.x. it would be great to hear 'make test' reports with as
> many perls/os-es/options/etc. to ensure no breakage for 1.25 sometime next
> week. thanks.

FreeBSD 4.2-STABLE #0: Wed Nov 22 12:06:36 PST 2000
Server: Apache/1.3.15-dev (Unix) mod_perl/1.24_02-dev (both HEAD in CVS)
perl 5.6.0 (old build for FreeBSD 4.0-RELEASE; see perl -V below)

% perl Makefile.PL DO_HTTPD=1 APACHE_SRC=../../httpd/apache-1.3/src \
USE_APACI=1 EVERYTHING=1

Seems to function as expected.

--
Sander van Zoest [sander@covalent.net]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/

% perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=freebsd, osvers=4.0-release, archname=i386-freebsd
uname='freebsd escher.vanzoest.com 4.0-release freebsd 4.0-release #2: tue jul 18 17:32:34 pdt 2000 sander@escher.vanzoest.com:usrsrcsyscompileescher i386 '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O', gccversion=2.95.2 19991024 (release)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=true
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lgdbm -lm -lc -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under freebsd
Compiled at Jul 31 2000 14:31:38
@INC:
/usr/libdata/perl/5.6.0/mach
/usr/libdata/perl/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005
/usr/local/lib/perl5/site_perl
.

On Wed, 27 Dec 2000, Daniel Jacobowitz wrote:

> I assume that if Apache is built with LFS, we do need them (though I
> think apxs will take care of that). What about if perl is - can we
> really get away without not using LFS when perl is?

we can get away with it because Perl never passes lfs related structures
to extensions. so the sizeof(struct stat) for example can be different
inside core Perl without causing problems in mod_foo land. unlike when
mod_perl is compiled with lfs flags, the sizeof(struct stat) is larger,
which changes the sizeof(request_rec), which is passed between apache and
mod_*

> Debian's spent a couple of weeks tracking down the problems enabling
> LFS in apache caused various modules (primarily PHP), and we've gotten
> most of them now, so I'd hate to back down again.

php has simply fixed their apxs cflags filter to include any ^-D flags,
nothing specific to lfs. i will need to query apxs for lfs flags if
USE_APXS=1 and turn them back on in mod_perl if present.

thanks everybody who tested!