Package: php5 Severity: normal Tags: lfs Hi!
I'm the author of several PHP extensions, and a user asked me to compile a binary for him. I've compiled the extension using a stock PHP install, and noticed that though the extension loaded fine on Debian and Ubuntu, it did not actually work. The exact same source code compiled on the Debian and Ubuntu systems worked fine. I've tracked this down to issues with reading files through PHP's streams layer. What I strongly suspect here is that Debian's LFS patch changes the size of the php_stream structure in a subtle way. However, from a compiled binary I have no way of detecting whether the LFS patch was actually applied. This makes it close to impossible to reject my extension from being loaded and/or tell them to use a LFS-compiled version that I obviously can also provide. If you, as Debian PHP Maintainer, find it necessary to break PHP's default ABI/API compatibility; could you at least reflect this in the API number so that your pre-compiled PHP refuses to load an extension compiled with the standard/a different ABI? You already add +lfs to the extension dir's default, so it should be easy enough. For example, something like: --- Zend/zend_build.h.orig 2011-02-10 11:26:12.000000000 +0000 +++ Zend/zend_build.h 2011-02-10 11:27:03.000000000 +0000 @@ -41,6 +41,10 @@ #endif /* for private applications */ +#if _FILE_OFFSET_BITS = 64 +#define ZEND_BUILD_EXTRA ",LFS" +#else #define ZEND_BUILD_EXTRA +#endif #endif cheers, Derick -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-25-virtual (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
