hi, (wow, de-lurking twice in one day!)
On Tue, Oct 14, 2008 at 04:06:11PM +0200, Johannes Schlüter wrote:
> The last time it was discussed it was said we can't easily turn it on
> globally as it would interfere with "small" stat pointer received by
> Apache and others, nobody proposed a patch and I doubt anybody will...
i think you're right: apache (specifically, libapr, i believe) passes
stat structs to/from the loaded modules, and thus needs to be built
with the same LFS flags, otherwise you will not have a happy server.
i believe the only other LFS related issue is with zlib which uses a long
somewhere that should have been an off_t iirc. in debian we enabled and
subsequently disabled LFS support a couple times while we worked this out
(it's enabled >= etch).
fwiw enabling the support is a matter of passing an extra couple compile
flags at ./configure time, so it's not like a user compiling php from
source is challenged to do this if they have already compiled apache
with the proper flags...
> Correct me when wrong: It would have been critical some one or two years
> ago, nowadays 64bit systems are available and used enough.
i think most maintstream distributions have already patched php to have
LFS suppport (redhat/fedora/debian/ubuntu/gentoo, from my knowledge though
i could be wrong on the non .deb distros). however, they have a slightly
easier situation for doing this, as they also provide the other utilities
(apache, zlib, etc), so they can ensure everything is compiled properly.
i think for php.net you may be in a more difficult position because you
don't control the distribution of the whole stack, so the best that you
could do is to detect the compile settings of the other components, and
incorporate them as CFLAGS at ./configure-time.
sean
signature.asc
Description: Digital signature
