We're running into problems with loading PHP extensions as MH_BUNDLEs
when PHP itself is an MH_BUNDLE.

Here's an ASCII depiction of what happens:

     +------------------------------------+
     | Apache (the host application)      |
     | defines: ap_func_1, ap_func_2 etc. |
     +++---------------------+------------+
      ||                     |
      ||                     | NSLinkModule(php_image, php_path,
      ||                     |      NSLINKMODULE_OPTION_PRIVATE);
      ||                     |
      ||                +----+------------+
      ||                | PHP (MH_BUNDLE  |
      |\ ap_func_1() --<  defines:        |
      |                 | php_func_1 etc. |
      |                 +----+------------+
      |                      |
      |                      | NSLinkModule(ext_image, ext_path,
      |                      |      NSLINKMODULE_OPTION_PRIVATE);
      |                      |
      |                 +-----------------+
      |                 | ext/mysql       |
      \ php_func_1() --<  (MH_BUNDLE)     |
                        +-----------------+


First, Apache loads the PHP module with the NSLINKMODULE_OPTION_PRIVATE
parameter to NSLinkModule (this happens in cctools/libdyld/dlopen.c).
The PHP module works fine, and dyld can satisfy all its undefined symbol
references from the host application (Apache).

Now, if PHP wants to load an extension (to support mysql databases,
in this example), it does the exact same thing. Here's where we run
into problems: the PHP extensions rely on an API exposed to them
in the PHP module. But because the whole PHP module has been loaded
with NSLINKMODULE_OPTION_PRIVATE, dyld can't find the PHP symbols
from the host application's global symbol table.

NSLinkModule for the mysql extension fails because of unsatisfied
symbol references and the whole app crashes. (I hear the crashing
bug has been fixed for Jaguar, though)

I can see two ways out of this for PHP:

 - If Apache ditched the NSLINKMODULE_OPTION_PRIVATE parameter
   when loading modules, I believe the problem would be solved.
   Since the Apache modules can be statically linked to Apache
   anyway, I can't see how this would cause any problems.

 - If we refactored PHP's codebase so that both the extensions
   and the PHP engine would link against a common framework which
   defined the PHP engine's API, this problem wouldn't exist.
   This would be a huge investment in effort, however -- one
   that nobody is really looking forward to.

I'm mainly looking for comments about the first of these two
options, plus of course any alternative ways to deal with this
issue. I'm *really* hoping I've missed some simple way to
make it all work :)

--Marko

-- 
Marko Karppinen - http://homepage.mac.com/marko/


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to