Everything

php

Need to inherit apxs compiler flags

php.internals

Rasmus Lerdorf

21 years ago

I spent a couple of hours today tracking down some very odd things I was
seeing calling sapi_get_stat() from an extension.  The symptom was that
the stat struct I was getting back looked messed up and shifted, as if
there was a binary compatibility mismatch.  I chased a number of things
until I realized that the Debian version of Apache is compiled using
-D_FILE_OFFSET_BITS=64 which turns regular stat() into a stat64() call.
That means that Apache is doing a stat64(), but PHP and any phpized
extensions are doing regular stat() calls.

So I think we need to trickle the "apxs -q CFLAGS" flags down into the
PHP build and into phpize.  On this Debian box I get:

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?

-Rasmus

Olivier Hill

21 years ago

On 7/17/05, Rasmus Lerdorf <rasmus@lerdorf.com> 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?

Sincerely,
Olivier

Rasmus Lerdorf

21 years ago

Olivier Hill wrote:

> On 7/17/05, Rasmus Lerdorf <rasmus@lerdorf.com> 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

Olivier Hill

21 years ago

Hello Rasmus,

Sorry to deviate from the original subjet, but could bug #33529 be
related to another sapi_get_stat() problem or just the way Apache
handles fstats? I have not enough inner working knowledge of the ZE to
track the bug down.

Sincerely,
Olivier

On 7/17/05, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Rasmus Lerdorf

21 years ago

Olivier Hill wrote:

> Sorry to deviate from the original subjet, but could bug #33529 be
> related to another sapi_get_stat() problem or just the way Apache
> handles fstats? I have not enough inner working knowledge of the ZE to
> track the bug down.

I don't see how it could be related, no.

-Rasmus