I’m trying to get PHP 5.0.0-dev to work under Cygwin. It hasn’t been much fun so far.
I’m working with George on a non-Yahoo! project, so I’ve gotta get PHP installed on a computer that I can use at home. So I figured I’d just build it our Windows 2000 laptop under Cygwin. Should be a piece of cake, right?
Last week I got PHP-4.3.1 running without much trouble. The only snag I ran into involved some mangling of the symbols in the xml (expat) extension. The workaround was to use the Cgywin installer to install a system (shared object) version of expat, then build PHP4 with
./configure --with-expat-dir=/usr instead statically linking in the bundled expat. It worked correctly as both a command-line binary and also when patched into the thttpd web server.
However, it turns out that George is using PHP 5, so I’ve gotta use the same thing. After a busy week last week, I finally got around to fetching the PHP5 source from CVS and started building it tonight.
First I had to install the Cygwin ports of the GNU build toolchain (autoconf, automake, libtool). Piece of cake. Then, much to my surprise, I got the thing to build with a simple
./buildconf && ./configure --with-expat-dir=/usr && make. But that’s when my luck ended:
radwin@radwin /usr/src/php-dev/php5 $ ./sapi/cli/php.exe -v Segmentation fault (core dumped) radwin@radwin /usr/src/php-dev/php5 $
Investigating in gdb (after I installed the Cygwin port), I found this:
(gdb) bt #0 0x610ab674 in memcpy () from /usr/bin/cygwin1.dll #1 0x004d6981 in ini_parse () at Zend/zend_ini_parser.c:1040 #2 0x004d6631 in zend_parse_ini_file (fh=0x22fb30, unbuffered_errors=1, ini_parser_cb=0x4a9ad0
, arg=0x51dd00) at /usr/src/php-dev/php5/Zend/zend_ini_parser.y:156 #3 0x004a9f27 in php_init_config () at /usr/src/php-dev/php5/main/php_ini.c:416 #4 0x004a625a in php_module_startup (sf=0x51b590, additional_modules=0x0, num_additional_modules=0) at /usr/src/php-dev/php5/main/main.c:1270 #5 0x005075a3 in main (argc=2, argv=0x10041800) at /usr/src/php-dev/php5/sapi/cli/php_cli.c:563 (gdb)
Bleh. A core in memcpy()? Something’s messed up. I hate it when this happens.
For kicks, I tried checking out the tree with the
PHP_5_0_dev_before_13561_fix tag, on the hunch that if someone bothered to tag the tree at some point, it probably worked that day. No luck; it dumps core in the same place.
I’m sure this would all be soooooo easy if I had a Linux box.