Provide pre-built Windows debug binaries

[ranvis]

Description

ARG_ENABLE('debug', ...); is defined in two places: phpize.js.in and config.w32.phpize.in. It makes user not possible to activate --enable-debug on configureing an extension because the latter definition overwrites PHP_DEBUG back to the default false.

The following code:

path\to\phpize
configure.bat --enable-debug --enable-extensionname

Resulted in this output:

---------------------------------------
| Build type        | Release         |
...

But I expected this output instead:

---------------------------------------
| Build type        | Debug           |
...

PHP Version

PHP 8.1.3

Operating System

No response

[cmb69]

It makes user not possible to activate --enable-debug on configureing an extension because the latter definition overwrites PHP_DEBUG back to the default false.

Isn't that actually desired? If I --enable-debug for an extension using a release PHP build, linking is usually going to fail. Same the other way round. So it seems to me that we should rather remove the --enable-debug option from phpize builds at all.

[ranvis]

Hmm, looks like what I expected was not what --enable-debug for extensions provides. I didn't meant to link against the different php.lib than generated phpize script expects, but to disable optimization or to define _DEBUG, like in CMake+Visual Studio targetting "Debug" instead of "Release" or "RelWithDebInfo". (In other words, by reading help I thought --enable-debug is "Debug" because --enable-debug-pack should be "RelWithDebInfo".)

By rewriting to ZEND_DEBUG=0 after configuring an extension with --enable-debug, it looks like to work; it builds and runs on release build PHP. Is ZEND_DEBUG the whole point of making interface incompatible? If so, for extensions I think ZEND_DEBUG can be propagated to say unconfigurable PHP_ZEND_DEBUG, so that --enable-debug can be retained?

[cmb69]

Well, --enable-debug is pretty close to "Debug" builds in Visual Studio, but the option also adds suffixes for libraries to link against (e.g. php8_debug.lib instead of php8.dll,, and for third-party libraries *_debug.lib files are linked if available).

Just defining ZEND_DEBUG=1 to be able to build with a release version would not try to link to the _debug.libs, but would still not work, since some functions exposed by the Zend Engine have different signatures for release and debug builds, respectively (e.g. efree() which includes the filename and lineno only for debug builds), and as such linking fails due to the name mangling for ZEND_FASTCALL.

Thus, I don't know whether it even would make sense to attempt such "mixed" builds. Why not just use release builds of extensions with release builds of php-src, and debug builds of extensions with debug builds of php-src?

[ranvis]

My intention was to build an extension with say assertion enabled using --enable-debug because I expected phpize and configure will adjust the enviroinment like compiling settings and interface changes caused by #defines in sync with the PHP it is going to link. It turned out it screws up if my "fix" is applied though. I think it doesn't make sense to "mix" different interface, and that is not I intended to do.

[cmb69]

Hmm, just enabling assertions may make some sense, but that would require further adjustments (ZEND_DEBUG would need to be broken up in two macros). I'm not convinced that this is the best way forward. Instead, I think it would make sense to also distribute debug builds for Windows, but that would need to be discussed on the internals mailing list.

[ranvis]

OK. I'm not sure about prebuilt downloadables, but trying to adjust build scripts sounds fragile compared to that.

[cmb69]

I'm not sure about prebuilt downloadables, […]

Me neither. For actual development of extensions, doing in-tree builds appears to be most sensible, so there wouldn't be an issue. Prebuilt debug binaries don't make sense for production (and even development of userland scripts); the only real benefit I see would be using them for CI.

To make some progress here, I'm going to repurpose this ticket as feature request to provide prebuilt Windows debug binaries. If you disagree, we can switch back to the original request/bug report.

[cmb69]

Just found this old ticket.

For actual development of extensions, doing in-tree builds appears to be most sensible,

That's the theory. In practise, most extensions are developerd on Linux (or maybe other POSIX systems), and many have only Windows CI jobs. Using full debug builds might make sense in this case, but is probably not really useful (well, maybe to be able to use PHP_WIN32_DEBUG_HEAP=1 which may catch some memory leaks). Instead something like --enable-debug-assertions (see #15544) and/or --enable-sanitizer (see #15978) might make more sense. On the other hand, we already ship builds for four configurations (x64/x86 and NTS/ZTS), and shipping four more debug builds, plus maybe more might be too much. Not sure how to proceed.