Thursday, October 11, 2007

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!

19 comments:

FGM said...

This is interesting to know: when you say PHP-GTK works, is it the old PHP-GTK 1.x, or the current PHP-GTK 2 branch ?

Most current builds seem to be created using MSVC instead.

(PHP-GTK webmaster)

FGM said...

(error in my previous comment: I'm not the webmaster of gtk.php.net, but of the php-gtk community site: http://www.php-gtk.eu/ )

You might want to just edit my previous comment.

Yaakov said...

PHP-GTK 2.0.0beta; I did not try 1.x.

Gareth said...

Hey, I installed your php port and was able to get CMS Made Simple up and running.

The only lib I had a problem with is php-gd. It seems that one of the dependencies is missing. I installed the cygwin gd 2.0.35 lib, but I think there is something else missing.

Gareth said...

Forgot to add: Good job, this works like a charm.

Yaakov said...

Re: gareth
The other dependency of php-gd is t1lib5 from the distro; check to see if that's installed.

Yaakov said...

Following up from my original post:

1) PHP 5.2.6 is now in the distro with additional plugins, as well as support for libtool-2.2.

2) php.cygclass now allows building both PEAR and PECL packages, as well as packages from other "channels"; just define PHP_CHANNEL accordingly.

kong said...

Hi,

First of all, many thanks for porting PHP on Cygwin.

I'm currently using PHP 5.2.10 in the release-2 directory and wonder if you have any plan to port the php-mbstring extension for 5.2.10 too?

Yaakov said...

Re: kong
Glad to help.
I was in a bit of a rush to get PHP into release-2 in order that I could ship php-qt from kdebindings and rkward. So I didn't build the prereqs for 3 of the extensions, mbstring included. Hopefully I'll have a chance for 5.2.11.

Yaakov said...

Re: kong

It seems that development of standalone libmbfl has stopped, and none of Fedora, Debian, Ubuntu, or Gentoo ship it. So I'll ship a php-mbstring with the static copy of libmbfl in 5.2.11.

Alex said...

I'm baffled... I can read here that you have ported PHP to Cygwin, and that it seems to work, yet I can't find it in the list of available packages when I run the installer.

Am I missing something?

Yaakov said...

PHP is still not part of the Cygwin distro. You need to follow these instructions to install the extra packages in Cygwin Ports.

Loren said...

Any chance of adding slite3 in the future?

Nigel said...

I recently installed the PHP package to enable me to do some web development on my laptop. I worked like a dream - just on problem: no IMAP support. Is there any chance that the IMAP extension will be ported soon?

Yaakov said...

Re: @Nigel

The IMAP extension requires c-client, but after trying, I see the Cygwin c-client package isn't up to the task. I'll need to get that fixed before I can ship php-imap.

infected said...

Hi Yaakov,

Any news on the PHP IMAP extension for Cygwin?

Yaakov said...

Re: @infected:

No, sorry.

Martin Pircher said...

Yaakov, thanks for PHP for Cygwin! I really love to work within cygwin, and PHP is really missing there.

I hope that the problem with c-client will be fixed so you can release php-imap, but as you find posts related to cygwin/imap/c-client dating back to 2002 I doubt this will ever happen?

Wouldn't it be an option if YOU would include a proper c-client for the module? AFAIK php uses the UW imap c-client which has been ported to cygwin[1] or take the current one[2] from UW?

[1] http://sourceforge.net/projects/uw-imap-cygwin (2000a)
[2] ftp://ftp.cac.washington.edu/imap/c-client.tar.Z (2007e)

Yaakov said...

Re: Nigel, infected, Martin Pircher:

After further research, I believe I have found a working solution with the existing Cygwin uw-imap/c-client. I'm in the middle of a massive PHP 5.4/Python 2.7/Sugar 0.98/Xine 1.2 upgrade/rebuild which need to be shipped in tandem; the exact timing depends on Python 2.7 going stable, which is currently scheduled for early February.