[PATCH] primitive load order deps for unix build system

php.internals

Wez Furlong

22 years ago
I've cooked up a patch [1] that causes extension modules to be initialized in an order appropriate to their dependencies. (in other words, it only affects internal_functions.c during configure time). The heart of the patch is an awk script that spits out the module_ptr structures according to the dependencies it spots in config*.m4 files. You mark a dependency using a new (dummy) macro: PHP_ADD_EXTENSION_DEP(extension, extension-it-depends-upon) This mirrors the ADD_EXTENSION_DEP that we have in the win32 build; this patch is effectively a port of the same kind of code from the win32 build. Now, my awk is a little rusty (it's been more than 6 years since I used it for anything serious), so that part definitely has room for improvement. I'd like to get this into the tree for PHP 5.0, as it will help eliminate some hacks (like SPL and SimpleXML have at the moment). Please test it, particularly on non-Linux platforms (check my awk portability!) to make sure it doesn't mess things up. If someone feels like cleaning up my awk, feel free. If someone can do it all in 100% portable bourne shell (!) feel free also :) --Wez. [1] http://www.php.net/~wez/configure-deps.diff

Andi Gutmans

22 years ago
How many platforms did you check this one? Andi At 08:34 PM 5/20/2004 +0100, Wez Furlong wrote:

Wez Furlong

22 years ago
Only linux so far. I can check it out on fbsd and solaris a little later. --Wez.

Andi Gutmans

22 years ago
Well the main problem is that awk might behave differently on all sorts of non-GNU systems (Sun, AIX, HP etc.). Is it important to include this in 5.0? At 09:22 AM 5/21/2004 +0100, Wez Furlong wrote:

Derick Rethans

22 years ago
On Fri, 21 May 2004, Andi Gutmans wrote:
> Well the main problem is that awk might behave differently on all sorts of > non-GNU systems (Sun, AIX, HP etc.). > Is it important to include this in 5.0?
I think it is important enough, as there is currently on way of doing this correctly, and it has been a (minor) problem for ages. regards, Derick

Wez Furlong

22 years ago
For people that want to build modular extensions (such as PDO) as static, it is. My preference for that is to require it to be built as shared (via PECL), so I'm not going to push the patch. If there are people out there with those other systems, it would be nice if they could test the patch before next week so that we can have a better evaluation of it. Despite PDO being a PECL-only extension by design, a number of people are already attempting (and failing!) to run it as static, because the module init order is undefined. --Wez.

Rasmus Lerdorf

22 years ago
On Fri, 21 May 2004, Wez Furlong wrote:
> Despite PDO being a PECL-only extension by design, a number of people are > already attempting (and failing!) to run it as static, because the module init > order is undefined.
What is the incentive to build it static? Performance? If you simply build a non-pic shared library there is no performance benefit at all. In fact, we should probably consider making this the default on platforms that support non-pic shared libs as our libs aren't general-purpose shared libraries, they are very much single-purpose libs designed to just be linked into a single binary. -Rasmus

Edin Kadribasic

22 years ago
On Friday 21 May 2004 20:25, Rasmus Lerdorf wrote:
> What is the incentive to build it static? Performance? If you simply > build a non-pic shared library there is no performance benefit at all. > In fact, we should probably consider making this the default on platforms > that support non-pic shared libs as our libs aren't general-purpose shared > libraries, they are very much single-purpose libs designed to just be > linked into a single binary.
1. You cannot simply build non-pic shared library. 2. For debugging purposes having .so's suck. Edin

Rasmus Lerdorf

22 years ago
On Fri, 21 May 2004, Edin Kadribasic wrote:
> On Friday 21 May 2004 20:25, Rasmus Lerdorf wrote: > > What is the incentive to build it static? Performance? If you simply > > build a non-pic shared library there is no performance benefit at all. > > In fact, we should probably consider making this the default on platforms > > that support non-pic shared libs as our libs aren't general-purpose shared > > libraries, they are very much single-purpose libs designed to just be > > linked into a single binary. > > 1. You cannot simply build non-pic shared library.
If we changed our default to non-pic it would be trivial.
> 2. For debugging purposes having .so's suck.
It's only marginally more inconvenient. You can always just preload them and then you won't be able to tell the difference at all. -Rasmus

Andi Gutmans

22 years ago
If people can step up and test it on a few of the non-GNU systems I mentioned (and possibly others) then I wouldn't object to commiting it. Any volunteers? Andi At 11:37 AM 5/21/2004 +0100, Wez Furlong wrote:

Magnus Maatta

22 years ago
On Friday 21 May 2004 12.41, Andi Gutmans wrote:
> If people can step up and test it on a few of the non-GNU systems I > mentioned (and possibly others) then I wouldn't object to commiting it. Any > volunteers? >
Tru64 UNIX 5.1/A/B, HP-UX 11.11/22i (or whatever), and possibly some other strange systems too. /Magnus
-- BOFH Excuse #422: Someone else stole your IP address, call the Internet detectives!

Magnus Maatta

22 years ago
On Friday 21 May 2004 13.13, Magnus Määttä wrote:
> On Friday 21 May 2004 12.41, Andi Gutmans wrote: > > If people can step up and test it on a few of the non-GNU systems I > > mentioned (and possibly others) then I wouldn't object to commiting it. > > Any volunteers? > > Tru64 UNIX 5.1/A/B, HP-UX 11.11/22i (or whatever), and possibly some other > strange systems too.
The updated patch works fine on: * Red Hat Enterprise Linux AS release 3 (Taroon Update 2) AMD Opteron * HP Tru64 UNIX 5.1B Alpha EV7 * HP HP-UX 11i 11.22 Intel Itanium2 * HP HP-UX 11i 11.23 Intel Itanium2 /Magnus
-- Bringing computers into the home won't change either one, but may revitalize the corner saloon.

Wez Furlong

22 years ago
We've done a fair bit of testing, refinement etc. on a number of systems. There are only two problem cases: mawk: runs, but doesn't appear to change the deps order. In other words, it doesn't make any difference, but at least it doesn't break the build. Solaris /usr/bin/awk: doesn't like user defined functions. The xpg4/bin version does, so this is ok; we can detect and use it even if it is not in the user supplied PATH. Gawk, nawk and other awks all appear to run the script just fine. We’ve updated the patch: http://www.php.net/~wez/configure-deps.diff I've personally tested this on Linux, Solaris 8 (thanks Jay) and OS X 10.2. Magnus has tested whole boat load of different platforms, and I've had word that it works on freebsd 4.8 (x86). If there are any other quirky systems (such as AIX or IRIX) out there and you have access, please test it. You can find instructions on this at: http://netevil.org/node.php?nid=43 Thanks! --Wez and Magnus

Sascha Schumann

22 years ago
Wez, can you please ensure that the awk script works on BSDI. We have had bad surprises with that particular platform before, because they are sometimes out of touch with the rest of the BSD camp. So, even if it works on FreeBSD, you cannot fully rely on that information. Thanks - Sascha On Wed, 26 May 2004, Wez Furlong wrote:

Wez Furlong

22 years ago
Does anyone have a BSDI box to test this on? --Wez.

Uwe Schindler

22 years ago
i can do Solaris (and MacOSX - but thats GNU) later this evening. At 12:41 21.05.2004, Andi Gutmans wrote:
>If people can step up and test it on a few of the non-GNU systems I >mentioned (and possibly others) then I wouldn't object to commiting it. >Any volunteers? > >Andi > >At 11:37 AM 5/21/2004 +0100, Wez Furlong wrote: >>For people that want to build modular extensions (such as PDO) as static, it >>is. >> >>My preference for that is to require it to be built as shared (via PECL), so >>I'm not going to push the patch. If there are people out there with those >>other systems, it would be nice if they could test the patch before next week >>so that we can have a better evaluation of it. >> >>Despite PDO being a PECL-only extension by design, a number of people are >>already attempting (and failing!) to run it as static, because the module >>init >>order is undefined. >> >>--Wez. >> >> >> > -----Original Message----- >> > From: Andi Gutmans [mailto:andi@zend.com] >> > Sent: 21 May 2004 11:27 >> > To: Wez Furlong; internals@lists.php.net >> > Cc: 'Sascha Schumann' >> > Subject: RE: [PHP-DEV] [PATCH] primitive load order deps for >> > unix build system >> > >> > Well the main problem is that awk might behave differently on >> > all sorts of >> > non-GNU systems (Sun, AIX, HP etc.). >> > Is it important to include this in 5.0? >> > >> > At 09:22 AM 5/21/2004 +0100, Wez Furlong wrote: >> > >Only linux so far. I can check it out on fbsd and solaris a >> > little later. >> > > >> > >--Wez. >> > > >> > > > -----Original Message----- >> > > > From: Andi Gutmans [mailto:andi@zend.com] >> > > > Sent: 21 May 2004 05:47 >> > > > To: Wez Furlong; internals@lists.php.net >> > > > Cc: 'Sascha Schumann' >> > > > Subject: Re: [PHP-DEV] [PATCH] primitive load order deps for >> > > > unix build system >> > > > >> > > > How many platforms did you check this one? >> > > > >> > > > Andi >> > >> > >> > > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php > >
----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Erlangen, Germany

Zeev Suraski

22 years ago
At 13:36 21/05/2004, Derick Rethans wrote:
>On Fri, 21 May 2004, Andi Gutmans wrote: > > > Well the main problem is that awk might behave differently on all sorts of > > non-GNU systems (Sun, AIX, HP etc.). > > Is it important to include this in 5.0? > >I think it is important enough, as there is currently on way of doing >this correctly, and it has been a (minor) problem for ages.
If it's been a minor problem for ages, then why the sudden rush to put it in just before coming out with a major version..? We seem to have enough momentum here to start a nice 5.1 as soon as 5.0 is released, in just 4 or 5 weeks... I wouldn't be the party pooper if everybody else thinks it's a good idea, and maybe it's because to me the build system always looked like black magic, but I feel that doing this change so late in the process is begging for trouble :) Zeev

George Schlossnagle

22 years ago
On May 21, 2004, at 8:32 AM, Zeev Suraski wrote:
> At 13:36 21/05/2004, Derick Rethans wrote: >> On Fri, 21 May 2004, Andi Gutmans wrote: >> >> > Well the main problem is that awk might behave differently on all >> sorts of >> > non-GNU systems (Sun, AIX, HP etc.). >> > Is it important to include this in 5.0? >> >> I think it is important enough, as there is currently on way of doing >> this correctly, and it has been a (minor) problem for ages. > > If it's been a minor problem for ages, then why the sudden rush to put > it in just before coming out with a major version..? We seem to have > enough momentum here to start a nice 5.1 as soon as 5.0 is released, > in just 4 or 5 weeks... I wouldn't be the party pooper if everybody > else thinks it's a good idea, and maybe it's because to me the build > system always looked like black magic, but I feel that doing this > change so late in the process is begging for trouble :)
It's a major problem for PDO, which won't be in 5.0, but will (hopefully) be in 5.1 and which we'd like to encourage people to use with 5.0 via PECL. As modules become more inter-dependent, and as they try to use/interact with 'core' features like simplexml, curl, etc. this becomes a bigger and bigger hassle. George