Re: 4.0.2 + 4.0.3p1 not binary compatible?

To be honest it hasn't really been much of an issue in the past. Since we distribute most PHP extensions with PHP it hasn't bitten us and nobody has complained. Yes, we have thought about it, but the big ugly threat of thousands of users screaming because of a binary-incompatible change just hasn't been there. We have however thought about the issue and there is a ZEND_MODULE_API_NO that gets checked on a dlopen(). See ext/standard/dl.c down around line 230: if ((module_entry->zend_debug != ZEND_DEBUG) || (module_entry->zts != USING_ZTS) || (module_entry->zend_api != ZEND_MODULE_API_NO)) { php_error(error_type, "%s: Unable to initialize module\n" "Module compiled with debug=%d, thread-safety=%d module API=%d\n" "PHP compiled with debug=%d, thread-safety=%d module API=%d\n" "These options need to match\n", module_entry->name, module_entry->zend_debug, module_entry->zts, module_entry->zend_api, ZEND_DEBUG, USING_ZTS, ZEND_MODULE_API_NO); DL_UNLOAD(handle); RETURN_FALSE; } It looks like that change should have prompted a bump of the module api identifier and this wasn't done. -Rasmus On Mon, 4 Dec 2000, Doug MacEachern wrote: > seems the change in zend_compile.h that moves `filename' from zend_op to > zend_op_array breaks extension binary compatibilty (sizeof() structures > have changed). so if i have an extension compiled with 4.0.2, it will > core dump when run under 4.0.3p1 and vice-versa. is there an effort to > maintain extension binary compatibility between minor releases, or at > least a way for php to detect binary in-compatibility in extensions? > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >