Repository navigation
Provide pre-built Windows debug binaries #8170
Description
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-extensionnameResulted 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
Activity
Fix phpGH-8170: --enable-debug configure option on Windows.
cmb69 commentedon Mar 4, 2022
Isn't that actually desired? If I
--enable-debugfor 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-debugoption from phpize builds at all.ranvis commentedon Mar 4, 2022
Hmm, looks like what I expected was not what
--enable-debugfor 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-debugis "Debug" because--enable-debug-packshould be "RelWithDebInfo".)By rewriting to
ZEND_DEBUG=0after configuring an extension with--enable-debug, it looks like to work; it builds and runs on release build PHP.Is
ZEND_DEBUGthe whole point of making interface incompatible?If so, for extensions I think
ZEND_DEBUGcan be propagated to say unconfigurablePHP_ZEND_DEBUG, so that--enable-debugcan be retained?cmb69 commentedon Mar 7, 2022
Well,
--enable-debugis 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=1to 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 forZEND_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 commentedon Mar 9, 2022
My intention was to build an extension with say assertion enabled using
--enable-debugbecause I expectedphpizeandconfigurewill 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 commentedon Mar 10, 2022
Hmm, just enabling assertions may make some sense, but that would require further adjustments (
ZEND_DEBUGwould 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 commentedon Mar 11, 2022
OK. I'm not sure about prebuilt downloadables, but trying to adjust build scripts sounds fragile compared to that.
cmb69 commentedon Mar 15, 2022
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.
[-]--enable-debug configure option does not take effect on Windows.[/-][+]Provide pre-built Windows debug binaries[/+]cmb69 commentedon Oct 19, 2024
Just found this old ticket.
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=1which 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.