Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74533
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.53 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
In-Reply-To: <1401207948.2998.77.camel@guybrush>
References: <CALJZF3gdNrEmr1tR05Gx35ewzydsAx58nbxkA4FzCUqVz1gRAw@mail.gmail.com>
	<1401193927.2998.50.camel@guybrush>
	<FDFBD40A-776A-473C-90FD-B75B2A462E60@gmail.com>
	<CALJZF3hZ_xx7XJ37dRq8uDO=QsgG=NKoHkd_34LrJk87XB1f4Q@mail.gmail.com>
	<1401200710.2998.56.camel@guybrush>
	<CALJZF3jTvq-vBciNrGrSeq8BNSNbnuOpfwmDBUhyic_gmC_5iw@mail.gmail.com>
	<1401205632.2998.67.camel@guybrush>
	<CALJZF3ie8pbz+o+hhYieaej7h5mEzHfL7-BkCgF4a=Y-VB0nag@mail.gmail.com>
	<1401207948.2998.77.camel@guybrush>
Date: Tue, 27 May 2014 18:58:06 +0200
Message-ID: <CALJZF3jWeWPnTk6YORMaKHRw1hPqSQMy5AsEwhK0W7oPXd81PA@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf303a2eab925a4204fa64993c
Subject: Re: [PHP-DEV] Linking and autoloading of dependent extensions
From: mike@php.net (Michael Wallner)

--20cf303a2eab925a4204fa64993c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 27 May 2014 18:26, "Johannes Schl=C3=BCter" <johannes@schlueters.de> wro=
te:
>
> On Tue, 2014-05-27 at 18:09 +0200, Michael Wallner wrote:
> >
> > On 27 May 2014 17:47, "Johannes Schl=C3=BCter" <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 thin=
k
> > > 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

--20cf303a2eab925a4204fa64993c--