On Tue, 2014-05-27 at 18:09 +0200, Michael Wallner wrote: On 27 May 2014 17:47, "Johannes Schlüter" wrote:
On Tue, 2014-05-27 at 17:30 +0200, Michael Wallner wrote:
Well, ok... so that's absolutely not the problem I'm trying to solve.
You can still load that stubbornly named extensions manually and
nothing will complain, even if something has a dependency on it.
I'm about e.g. pecl install & going ahead without reordering extension
The issue is this can pull in the wrong extension giving the user a hard
time to understand how and why that happens.
Could you give an example? I can hardly imagine a likely scenario...
Whenever there are multiple versions of an extension around. This
happens for different (bad) reasons.
And I don't think this will solve the "pecl install & going ahead" wish
- what should "pecl install" do? - Add new extensions to the end of the
file? So it will be loaded two times?
Wa? pecl will download, build and install the dependencies listed in package.xml.
It is smart enough to not add the same extension line twice. Frankly,
I'm not sure what you are talking about.
It is enough to add it once in the wrong place (too late) to produce a
"already loaded warning" - first the extension will be pulled in by the
new magic, then by the line from php.ini.
pecl install also won't know which php.ini file(s) to edit - some setups
use different files for cli and web server etc.
I think the solution is more in the loading and startup logic. I think
we should only load explicitly mentioned extensions (or alternatively
Which is the way it currently is, isn't it?
nope. php_load_extension() opensthe file, fetches the module structure
and starts it up in one go.
*all* extension in extension dir, while that has issues, too, think i.e.
Sounds crazy. Distributions also ship lots of not enabled extensions.
The could solve it by symlinking "activated" ones in a directory which
is configured as extension dir. Mentioned it mostly for brainstorming
Windows where we distribute a bunch of dlls which require some 3rd party
libs in proper places), then analyze the dependencies, order the startup
call accordingly and start them up.
(this all won't solve issues where lazy linking doesn't work and we need
system level symbols from other extensions, though ... but I think
systems without working RTLD_LAZY are rare these days)
My approach is quite unintrusive, should work in 90% of cases as
before, and in 10% improved as intended. (Given I solve the
... and gives harder to debug behavior in case a system isn't properly
setup, which likely means there is a less experienced user, which will
have an even harder time.