Re: Linking and autoloading of dependent extensions

On 27 May 2014 18:26, "Johannes Schlüter" <johannes@schlueters.de> wrote: > > 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. So you are not able to provide an example either? If you manage multiple versions of extensions, you're probably also capable of managing your extension section to be loaded in proper manner. > > > 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. Which I already mentioned is probably possible to mitigate. > pecl install also won't know which php.ini file(s) to edit - some setups > use different files for cli and web server etc. You obviously do not use the pecl command. It edits whichever file you tell it to maintain. > > > 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. Which is not possible for extensions that use symbols exportet from dependent extensions, it won't dlopen. > > > *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. I wouldn't call such a system not properly set up, but rather severely fucked up :) Re-reading the manpage it's now obvious why my first tests failed, which caused me to abandon RTLD_LAZY. So back to the start. Anyway, whatever I propose, I cannot fix your extension naming quirks. Cheers, Mike