Olivier Hill wrote:
> On 7/17/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> 
>>3:47pm colo:~> apxs -q CFLAGS
>>-DLINUX=22 -DEAPI -DTARGET="apache" -DHAVE_SET_DUMPABLE
>>-DDB_DBM_HSEARCH=1 -DDEV_RANDOM=/dev/random -DUSE_HSREGEX -O1  -g -Wall
>>-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>>
>>Anybody see a better way to solve this?
> 
> 
> IIRC, Gentoo devs added those flags (-D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64) on PHP ebuilds because it caused
> incompatibilities with Apache that was compiled with those flags.
> Besides, I can use to be able to open >2G files from PHP where Apache
> can.
> 
> I'm +1 on this. Anybody can anticipate a problem doing that sort of
> change? Could it break with some libs that were not compiled with 64
> bits FPs or am I missing something?

Yeah, there are problems doing this.  We do actually inherit the flags,
but only to the sapi build.  Which makes sense.  But that also means
that the Apache sapi and the cli sapi built at the same time could have
different ideas of the size of a stat struct.

I don't see any way around this.  I think what we need to do is abstract
the sapi_get_stat() call to the point where it returns our own version
of the stat struct that is always known.  The sapi itself can work out
how to convert the native stat struct to the php version.  That way
extensions won't be sapi-dependant.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to