Debugging doze configuration

From: Date: Mon, 01 Sep 2008 12:48:44 +0000
Subject: Debugging doze configuration
Groups: php.internals.win 
Request: Send a blank email to internals-win+get-145@lists.php.net to get a copy of this message
I found out why Phar's always built shared in snapshots. If you have two ARG_*() calls in a core module config.w32, the first is taken as core but the second is forced on as shared. This isn't new behaviour, I just never saw it before because statically-built core modules with a second ARG_*() are rare, to say the least. The killer was a line in our config.w32: PHP_PHAR_SHARED = PHP_PHAR_NATIVE_SSL_SHARED; So, the reason we have our problem in Phar is because NATIVE_SSL_SHARED is automatically set to TRUE by the snapshot build and then assigned to PHP_PHAR_SHARED. My bad. However, there's no good way around this. I *can* fix it in our config.w32, but it will look klutzy because it needs to include a check for snapshot builds. It's a bit more robust than relying on a temporary hack, though, and of course we only have the problem in PHP_5_3 branch. Pierre's change to the EXTENSION() function - setting PHP_EXT_SHARED to the value of the third argument, where it exists - was never intended to fix that issue, and in fact that argument is supposed to force a permanent static or shared build. That hack is there because the build would otherwise crash the first time a non-optional module is referenced, since non-optional modules are created by opting out of configuration altogether. There didn't used to be many of those, but there are in 5_3... SPL and PCRE among them, both of which have dependencies. I came along and fixed a crash bug in the dependency logic that showed up after SPL and PCRE became non-optional, but didn't realise I'd merely shifted the problem further along the line. Pierre did, but didn't report it. He tried to fix it by setting PHP_EXTNAME="yes" in some of the non-optional module config files - i.e. the ones that currently have dependencies in them. A more robust fix would be to check for PHP_EXTNAME on entering the EXTENSION() function: try { eval("PHP_" + EXT + ";") /* Non-optional modules are undefined */ } catch (e) { eval("PHP_" + EXT + "= 'yes';"); eval("PHP_" + EXT + "_SHARED = shared;"); } and drop the existing workarounds. This really should happen prior to 5.3.0. Our own issue in Phar is probably so rare as to be not worth changing the 'winner takes all' approach in the snapshot build, but it would be do-able. Just not when we're on the edge of a release. - Steph

« previous php.internals.win (#145) next »