Re: diagnosed but hard to fix segfault

Sounds like you want to force the extension to build as a shared extension.... but if you already have php-gtk.dll it's doing that. The problem is probably something else. My suggestion is to run it under a debugger and see where it blows up. My personal preference for this kind of thing is WinDBG, part of Debugging Tools for Windows (google will show you where on microsoft.com you can get this). Run WinDBG, then tell it to "open executable", browse to your php.exe and enter the command line arguments (path to the script) and then click OK; it will load up php but pause it before it runs main(). Then click the "go" button (F5). It should run and catch the problem before it blows up. The view menu will let you see the call stack. You should be able to do the same kinds of things with the visual studio/visual c++ debugger that you already have installed. Although it has a more friendly interface, I personally find that it takes too long to launch and occupies too much memory for my tastes. For best results, make sure you're building a debug build of PHP and a debug build of php-gtk.dll. (in fact, the debug-ness of both those things must match in any case). As for building extensions from outside the main trees, you're the first to have tried that with the new build system... In theory there should be no problems if your compiler is using the same header files and simply links against the .lib file. As a hack, I'd suggest sticking your php-gtk sources in the following arrangement: php5src/configure.js pecl/phpgtk/config.w32 eg: have a pecl dir alongside the php-src checkout, and under that, have the gtk sources. The built-in configure process should pick that up as though it were a regular pecl package and build it as part of the main build. Not quite what you were asking for, but useful to verify that the package works. Hope that helps, --Wez. Steph wrote:

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