PHP on Cygwin

Efforts to bring PHP to Cygwin have waxed and waned over the years. One of the big problems, at least with PHP5, was dealing with shared extensions, as discussed last year in this thread. Unfortunately the sources mentioned there are no longer available, so unfortunately I didn't even have that to start with.

PHP consists of multiple interpreters (called SAPIs) which serve different purposes, e.g. a command-line interface, a CGI interface, Apache modules, etc., together with dozens of extensions written in C, which can either be built in to the interpreter or can exist as loadable modules. Additional C extensions are also available on PECL, which must be built as shared modules, as they are installed after building the runtime.

PHP extensions require symbols that would normally be (on Linux) in the interpreters, but that doesn't work for Cygwin because all symbols must be resolved at link time. But if an extension is linked against one SAPI but loaded by another, a segfault will result.

The solution is, as is done with MSVC, is to build almost all the core sources into a shared library, then link the SAPIs (with just their SAPI-specific code) and the extensions against the library. Implementing this within the autotool framework took a lot of work to get right, but it looks promising so far: both the CLI and CGI load all the modules, PECL extensions can be built, and even better, PHP-GTK is working.

This solution does require a few minor changes to the build procedure for PECL extensions, hence I've added php.cygclass to cygport for this purpose; in most cases, a one-liner 'inherit php' is enough.

PHP, PHP-GTK, and several other sample PECL extensions are now in CVS; the PHP .cygport is heavily commented, which should help make sense of what was needed to make this work, for those who are interested. PHP, with separate packages for each of the standard extensions, as well as PHP-GTK, will be available in binary form with the next upload.

BTW, at this point I have no intention of packaging PEAR (pure PHP extension) libraries, as they require no compilation; instead, just install php-pear and install them as on any other platform.

If anyone is running Apache, then I would like to hear if those SAPIs are working; please post a comment below or to the mailing list.

Enjoy!

SECURITY: libsndfile

The Gentoo Security team has announced a security vulnerability in all versions of libsndfile. I have rebuilt libsndfile with their patch, as well as for the new FLAC API. This is now in CVS, and will be included in the next upload.

Pidgin and SILC

I just finished building Pidgin 2.2.1 with SILC support. But I came across an interesting problem:

SILC can either use GNU MP or its own code for multiple-precision arithmetic, and that causes the problem, because "silcmp.h" begins with:

#ifdef SILC_MP_GMP
#include "mp_gmp.h"
#else
#include "mp_tma.h"
#endif

Only one of those "mp_*.h" headers will be installed, depending on which MP is enabled. But that means that anything building against SILC needs to know if GMP was used or not; if it was, and you don't #define SILC_MP_GMP, then you obviously get errors at compile time (since mp_tma.h is not installed in that case).

For Pidgin, I just worked around this by adding -DSILC_MP_GMP to CPPFLAGS, but there should be a better solution:

1. The best solution would be for SILC to add this flag to silc.pc via an AC_SUBST.


2. Otherwise, Pidgin (and other software depending on SILC) should be calling in configure.ac:
   

   CFLAGS_save="$CFLAGS"
   CFLAGS="$CFLAGS $SILC_CFLAGS"
   AC_CHECK_HEADER(mp_gmp.h, silc_mp_gmp=yes)
   CFLAGS="$CFLAGS_save"
   if test "x$silc_mp_gmp" = "xyes"; then
   AC_DEFINE(SILC_MP_GMP, 1, [Define if SILC uses GNU MP])
   fi

Now you understand why the first solution is much better. But does anyone know how other distros deal with this? Comments Thoughtfully Considered.

New blog

As it seems that blogging is becoming more common among open source projects, I decided it's only fitting that Cygwin Ports should join the club. Don't expect long essays here, but I will try to share my experiences from building and maintaining a wide variety of software on a not-so-common platform.

Also, this isn't meant to be a support forum; keep using the cygwin-ports-general mailing list for that.

SECURITY: xfs

X.org has announced that xfs (<1.0.5) contains several security vulnerabilities; an update is already in Ports CVS and will be included in the next upload.