Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74531
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
In-Reply-To: <CALJZF3ie8pbz+o+hhYieaej7h5mEzHfL7-BkCgF4a=Y-VB0nag@mail.gmail.com>
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>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-FOAP7maD7F6w1VHfR9Hd"
Date: Tue, 27 May 2014 18:25:48 +0200
Message-ID: <1401207948.2998.77.camel@guybrush>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] Linking and autoloading of dependent extensions
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

--=-FOAP7maD7F6w1VHfR9Hd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2014-05-27 at 18:09 +0200, Michael Wallner wrote:
>=20
> On 27 May 2014 17:47, "Johannes Schl=C3=BCter" <johannes@schlueters.de> w=
rote:
> >
> > 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 extensio=
n
> > > entries...
> >
> > The issue is this can pull in the wrong extension giving the user a har=
d
> > time to understand how and why that happens.
>=20
> 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?
>=20
> Wa? pecl will download, build and install the dependencies listed in pack=
age.xml.=20
> 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
>=20
> 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=
.
>=20
> Sounds crazy. Distributions also ship lots of not enabled extensions.=20

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 part=
y
> > libs in proper places), then analyze the dependencies, order the startu=
p
> > call accordingly and start them up.
> >
> > (this all won't solve issues where lazy linking doesn't work and we nee=
d
> > system level symbols from other extensions, though ... but I think
> > systems without working RTLD_LAZY are rare these days)
>=20
> 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


--=-FOAP7maD7F6w1VHfR9Hd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (SunOS)

iQEcBAABAgAGBQJThLyMAAoJEH3sTmn8nIPXNeAIAICY8+TZ11FXN3CYUXCVc0tw
6pySa1FWXXIdUokgNx/bsBs1JLsJ0L5yYgL6p2ITSTppUzg+4QO8yXkgq/B8qOcu
RwY926L+NxSG4w2sIDek4uDSJCmFsWEkVTetgOsvvTEfRCb2RDimITQC+Xa8LmLo
JsCVjeUeMbqY1VLIeaxukfMfqVVyQ03ehTopyG5w738n8Fl9SfHsFUBxYst9vbus
fJizvamqM6VpO1dIr0nKD3PkzoDn6NHMTPtP589L1dPYL7591Nzv8HL8Kkc1hM//
bKQGW2+tGi0tmYWEEIWGg8E66K3DKJL6VjyyXfYdFhqpbJrdIyq48bJQ81rqIF8=
=GU52
-----END PGP SIGNATURE-----

--=-FOAP7maD7F6w1VHfR9Hd--