internals:extensions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
internals:extensions [2013/04/10 09:19] jpauliinternals:extensions [2013/04/10 12:06] jpauli
Line 176: Line 176:
  
   Before PHP5.5, Zend extensions needed to be provided the full path to the extension (ini token "zend_extension="), such as /usr/lib/php/foo.so, whereas PHP extensions (using the ini token "extension=") just needed the file name and used the "extension_dir" ini directive to build the full path to load the extension.   Before PHP5.5, Zend extensions needed to be provided the full path to the extension (ini token "zend_extension="), such as /usr/lib/php/foo.so, whereas PHP extensions (using the ini token "extension=") just needed the file name and used the "extension_dir" ini directive to build the full path to load the extension.
-  As of 5.5, this in note the case any more and both PHP and Zend extension are loaded providing only the file name, not the full path.+  As of 5.5, this in not the case any more and both PHP and Zend extensions are loaded providing only the file name, not the full path.
      
 At this stage, PHP and Zend extensions have been parsed from ini files, but nothing more has been done. At this stage, PHP and Zend extensions have been parsed from ini files, but nothing more has been done.
  
 ===== Registering additionnal extensions from the SAPI module ===== ===== Registering additionnal extensions from the SAPI module =====
-Again before loading/registering anything from ini files, any SAPI may call ''php_module_startup()'' passing it an array of PHP extensions to load (pointers to zend_module_entry)+Again before loading/registering anything from ini files, any SAPI may call ''php_module_startup()'' passing it an array of PHP extensions to load (pointer to zend_module_entry*)
 Those get registered here, the same way statically compiled got registered just few steps before, to recall : Those get registered here, the same way statically compiled got registered just few steps before, to recall :
   * Checks for extension dependencies, but only against conflicts, so **it does not load any other extension** than the one it's been called with   * Checks for extension dependencies, but only against conflicts, so **it does not load any other extension** than the one it's been called with
Line 191: Line 191:
      
 ===== Loading the ini parsed extensions ===== ===== Loading the ini parsed extensions =====
 +
 +Here comes time where PHP will effectively **load** Zend and PHP extensions, calling some hooks onto them. ''php_ini_register_extensions()'' is called and does this job.
 +First thing to know : **Zend extensions are loaded before PHP extensions**
 +
 +==== Loading Zend extensions ====
 +''zend_load_extension()'' is called, the shared object is dlopen()'ed and two symbols are looked for :
 +  * zend_extension_entry
 +  * extension_version_info
 +
 +  If those symbols are missing, the Zend extension will fail to load
 +
 +Then API compatibility is checked from ''extension_version_info'' against current running PHP. Zend extension's ''api_no_check()'' may be called if mismatch.
 +After that, buildid is checked. Buildid is a combinaison of the previously checked API number, debug flag and thread safety flag (ZTS). Other components may be used for buildid check. Zend extension's ''build_id_check()'' function may be called as well, though it's pretty uncommon.
 +
 +   Usually, this system just checks that the extension contains code that will be loadable and undertsnadable by the PHP internal code actually loading it. For example, an extension built with ZTS activated will hit those checks and won't be loaded on a PHP running without ZTS.
 +   
 +After those checks, the Zend extensions get registered. ''zend_register_extension()'' is called to do this job.
 +A message is dispatched to all previously registered Zend extension to make them know a new Zend extension is beeing registered. Then, ''message_handler()'' is called on all already registered Zend extensions, and is given as argument the pointer to the beeing-registered extension.
 +This system has been designed so that Zend extensions may know each other, and eventually fail loading if they guess they are not compatible with each other.
 +
 +   Remember that there is no such thing like "dependencies" with Zend extensions. Only PHP extensions have a built-in dependency system with features we'll talk about later
 +   
 +
internals/extensions.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1