diagnosed but hard to fix segfault

Hi Wez, I ran my shiny new but painfully silent php-gtk.dll under the MSVC++ debugger last night, and found that php.exe isn't registering the php-gtk module as it should. It gets as far as module_registry_request_startup(): module->module_number 22 - module->name 0x00d01118 "php-gtk" 112 'p' module->request_startup_func 0x00b7eea0 module->type 1 '
' zend_printf 0x10004d04 _php_printf but then bails out. In zend_hash_apply(), pLast and pListNext for arKey 'php-gtk' are both completely data-free zones. From userland, php -m lists the loaded php-gtk module as expected, but php -v or any attempt to run a script while php-gtk.dll is loaded will crash PHP. I'm assuming the debug stuff and the userland stuff match up here. Today I looked through configure.js properly, and found that what happens during EXTENSION() includes adding the header with the module pointer declaration to main\internal_functions.c. That'll be where this falls down then, I guess? Not only is the (relative-to-src-root) giving the wrong module path information, but PHP is already built anyway. So, is there a way to build against an existing copy of php5ts.lib from outside the PHP source tree using the 'new' win32 build system? Or do I still need to use .dsp files to do this? Or am I swimming up completely the wrong creek in a paddle-free manner? - Steph