if you build mod_php for apache2 while you have -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE in your CFLAGS then apache will segfault when you attempt to have apache serv anything i would post a gdb run but when doing so gdb claims 'program exited normally' ... which it did i guess since apache caught the signal to die and did so accordingly ... note that: mod_php + apache1 + LFS == work apache2 + LFS == work mod_php + apache2 + LFS == work so i'd suggest adding this to the mod_php ebuild: use apache2 && filter-flags -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
So just to clarify: trying to force large file support using CFLAGS breaks mod_php with apache2, but it still does proper large file support anyway if you don't include the CFLAGS?
i didnt bother investigating whether php still accessed things with large file flags because it was kinda late and i just wanted the damn thing to work :) ill play around with the machine to find out
yes, the files are accessed in large file mode as far as i can tell from looking at the output of an extensive strace run so i guess if you just filter it out it should be fine
Fixed in CVS.
Sorry! Unfortunately, php can not handle large files without those defines. I haven't tested for the exact limit, but it is either 2GB or 4GB - ie max positive of either a signed or unsigned 32 bit integer. Anyway, if this could be applied only for mod_php, rather than php as well, I'd be happy too.
jstubbs: that's a direct contradiction of spanky's experimental results. both of you post up your versions of testing scripts, and i'll evaluate it myself before changing things.
jason@maguro ~/logger $ dd if=/dev/zero of=bigfile bs=1024 count=5242880 5242880+0 records in 5242880+0 records out jason@maguro ~/logger $ ls -sh bigfile 5.1G bigfile jason@maguro ~/logger $ php -r 'fopen("bigfile", "r");' Warning: fopen(bigfile): failed to open stream: File too large in Command line code on line 1 [ebuild R ] dev-php/php-5.0.1 -adabas -bcmath +berkdb -birdstep -bzlib -calendar -cdb -cpdflib +crypt -ctype -curl -curlwrappers -db2 +dba -dbase -dbm -dbmaker -dbx -dio -empress -empress-bcs -esoob -exif -fam -fdftk -filepro -flatfile -frontbase -ftp +gd -gd-external -gdbm -gmp -hyperwave-api +iconv -imap -informix -ingres -inifile -interbase -iodbc +jpeg -ldap -libedit -mcve -memlimit -mhash -mime -ming -mnogosearch -msession -msql -mssql +mysql -mysqli +ncurses -nis +nls -oci8 -odbc -oracle7 -ovrimos -pcntl -pcre -pfpro+png -posix -postgres -qdbm +readline -recode -sapdb -sasl -session -shared -sharedmem -simplexml -snmp -soap -sockets -solid -spell -spl -sqlite +ssl -sybase -sybase-ct -sysvipc -tidy +tiff -tokenizer +truetype -wddx -xml2 -xmlrpc -xpm -xsl +zlib 0 kB
BTW, the same thing happened with 4.3.8
i said mod_php + apache2, not the cmdline php ... i'll see if i cant test this again to see if it happens with mod_php-5.x
Yes, I know. The fix for this bug, however, removes the appropriate -D_* from dev-php/php as well by way of php-sapi.eclass. I don't mind if it's removed from mod_php, but removing it from php as well I think is a bit heavy handed.
my current toolchain and with mod_php-5.0.1 i'm not able to reproduce this anymore so we could just remove the filter-flags completely since i'm sure the gcc/glibc combo i used when i filed this bug are way past dead now
OK, just went through a minor circle of hell teasing out why I coulnd't serve file > 2GB in size from Apache (2.0.52-r1) with mod_php. After strace-ing Apache with and without mod_php, found that mod_php was the source of the issue. After modifying the php eclass at /usr/portage/eclass/php-sapi.eclass, commenting out the filter-flags which filtered the LFS CFLAGS, I re-emerged mod_php (stable version 4.3.9) after adding -D_FILE_OFFSET_BITS=64 to the CFLAGS in /etc/make.conf. Viola, happily viewing a 7.8 GB video from my mythtv box via VLC on a Windows 2000 client. So, while it would be better to have a "lfs" USE flag going forward, can we at least remove the filter-flags for lfs in this eclass, please? Thanks!
I would like to see a LFS support added into this too for the same reason as Jesse
for PHP 4 we added LFS support as we just wanted it in apache, this enforced us to enable it for mod_php 4 as well, or it would die otherwise; masked packages will be committed in a second, but do not use them *ALONE*, that is, if you wanna test them, you have to unmask the whole new apache-herd related commits (see package.mask); update apache including apr/apr-util-0.9.5 and recompile everything that directly and/or indirectly depends on apr.
could the posters on this bug please test that LFS support works with the latest mod_php/apache packages?
Works for me! Thank you all for your work. :)
LFS support has been dropped. It will return when Apache 2.2 is released.
Um, what?!? Why is it dropped when it works fine?!?
I really really dislike the move-back, and I've not been the one who fought for it, but obviousely, there must be no other way. trapni@battousai gentoo-x86 $ head -n14 dev-libs/apr/ChangeLog # ChangeLog for dev-libs/apr # Copyright 2000-2005 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/dev-libs/apr/ChangeLog,v 1.28 2005/05/09 14:44:25 beu Exp $ *apr-0.9.6-r3 (09 May 2005) *apr-0.9.5-r3 (09 May 2005) 09 May 2005; Elfyn McBratney <beu@gentoo.org> +apr-0.9.5-r3.ebuild, +apr-0.9.6-r3.ebuild: Rev bumps that remove LFS support from APR (has caused too many issues for mid-release introduction). The Apache tool-stack (net-www/apache, devs-libs/apr (this package) and dev-libs/apr-util) will need to be rebuilt once emerging this update.
OK. There must be some silly bureaucratic reason, because there certainly is no technical reason for this "roll back". But I thought Gentoo, and the Gentoo buracracy's, purpose was to move technology forward, not backward? It would seem from the _apr_ bug changelog entry that the bug is with apr, not the net-www/apache package? To compound things, apr is masked as *unstable*, so this decision, which rolls back a *stable* package, is done for a *masked* package? How silly is that? This is why a LFS USE flag would be key right now...
