[php-maint] LFS support in sight

[Steve Langasek]

On Sun, Nov 12, 2006 at 12:32:18PM +0100, sean finney wrote:
> On Sun, 2006-11-12 at 02:47 -0800, Steve Langasek wrote:
> > Peter Samuelson has helpfully tracked down the problem with libapr blowing
> > up when building code against it using -D_FILE_OFFSET_BITS=64, so I've now
> > been able to build an LFS-enabled libapache2-mod-php4 which doesn't segfault
> > -- w00t!

> nice, nice.  i'll be interested to see the details.

The apr_finfo_t struct has a member of type apr_ino_t, which is typedef'ed
directly to the system ino_t -- and the size of ino_t is not invariant with
respect to LFS (with -D_FILE_OFFSET_BITS=64, it's aliased to ino64_t
instead).  So this throws off the size of the whole apr_finfo_t struct and
screws up the offsets of most members within that struct besides.

> > Now, the thing is that LFS also changes the PHP extension API -- it's
> > *supposed* to, the current API can't handle 64-bittage -- which means we
> > ought to be documenting this change in the exported "phpapi" version that we
> > export everywhere, and get all the out-of-tree extension packages recompiled
> > for it, to avoid accidentally shipping an inconsistent set of extension
> > packages for etch.

> afaik none of the packages depending on the new php api have even been
> built yet, so maybe we can avoid bumping the api?

I was referring to php4 here, actually, which hasn't had a recent
ABI-changing upload.  I've been studiously avoiding acknowledging the
existence of php5 for the past year. >:)

Yes, for php5 the decision is easy because we already have an ABI change to
go through, so all we need to do is verify that the php5 packages really
work as intended. :)

> > Does anyone object to going ahead with this immediately?  The code is all
> > ready once I decide how to best go about retrofitting
> > patches/053-extension_api.patch, so all I need is for this list to give the
> > word.

> i say go for it.  we have the same problem in php5 so we should make a
> new upload of that as well.  also, it'd be worth a quick test that this
> doesn't cause problems for the apache 1.x module or any of the phpN-foo
> modules.

Yes, I'm going to check on apache 1.x as well. (Good riddance to the other
per-webserver SAPIs!)  Testing *all* of the modules is probably quite a bit
harder; I'm hoping to get away with relying on user testing to let us know
if there are any new LFS problems besides the ones we found out about last
time around. :/

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/