Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.128.176 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
Date: Tue, 28 Feb 2017 13:13:44 -0600
Message-ID: <CAESVnVqP6cprZ_2DfK_hkc6_Ym_MSpP-9UZQk551RGoCTXuhUA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: [Request for Comment] Loading dynamic libraries with cross dependencies.
From: pollita@php.net (Sara Golemon)

The average PHP extension is dependent only on the PHP runtime it was
built for and probably one or more 3rd party libraries.  However, a
special class of extensions (such as PDO drivers and much of the XML
family) have dependencies on other PHP extensions which may (or may
not) be preset at the time they are loaded in via ini settings and/or
dl().

This situation was partially addressed by Wez back in PHP 5.2 with the
addition of zend_module_dep in the module entry header.  Combined with
RTLD_LAZY during DL_LOAD() (a portability macro for dlopen()), this
allows modules to be inspected for dependencies and conflicts prior to
being registered with the runtime.

Unfortunately RTLD_LAZY has some limitations.  From `man dlopen`:
"""Lazy binding is performed only for function references; references
to variables are always immediately bound when the shared object is
loaded."""  Given PHP's heavy use of XG() macros to access "globals",
the odds of a missing symbol during module load is therefore fairly
high resulting in an inability to inspect zend_module_dep structures
and provide a meaningful error message to end users.

Why do I care what the error message looks like? Full disclosure: The
company I work for wants to know reliably what order to list
extensions in php.ini files that are partially autogenerated.  atm
this comes in the form of an explicitly curated relationships table,
but that's not the most scalable approach.
Additionally, resolving this will likely help other users when
presented with what are currently somewhat cryptic load errors. (e.g.
"Unable to load 'foo': unresolved symbol _libf2_blarg")


I'd like to open a discussion on how we might address this in future
releases of PHP.  Some back-of-the-napkin brainstorming has yielded
the following, but I'd love to hear others' thoughts on the subject:

Make use of the already extant PHP_ADD_EXTENSION_DEP config.m4 macro
to produce a look-aside data structure which can be accessed without
fully loading the extension.  This look-aside could be stored in an
arbitrary .text section in the DSO or as a separate file. (I prefer
bundling with the DSO for what I hope are obvious reasons).

-Sara