Re: Linking and autoloading of dependent extensions

On Tue, 2014-05-27 at 18:09 +0200, Michael Wallner wrote: > > On 27 May 2014 17:47, "Johannes Schlüter" <johannes@schlueters.de> 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 > > > entries... > > > > 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 purpose. > > 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 > install_root dilemma) ... 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. johannes

Attachment: [application/pgp-signature] This is a digitally signed message part signature.asc