I'm building a script that installs PHP 5.3.10 from source. One of the steps is to install apc and mongo support via pecl. I'm building the CGI/FastCGI version. This is on a box that formerly had mod_php installed.
If I do 'make install' of PHP (which installs a new pecl binary) and follow it up immediately with 'pecl install apc', the apc extension winds up here: /usr/local/lib/php/extensions/no-debug-zts-20090626 That's not what command line php and php-cgi are looking for, so they produce warnings and don't load the extensions. However If I do the pecl install later - possibly after restarting Apache with fastcgi enabled - it installs to the new, correct place: no-debug-non-zts-20090626 The warnings go away, and everything is great. This raises two questions about which no documentation seems to exist after quite a bit of searching and which raise questions about whether PHP is doing sensible things, so I took the liberty of bringing them to folks who actually understand PHP's internals. 1. You only get one pecl binary although you may have many SAPIs installed. mod_php defaults to thread-safe (and there seems to be no way to turn that off on Linux), while php-cgi does not. So how does pecl decide which way to build extensions? I tried setting extensions_dir via config-set, but that setting was ignored (unless perhaps it falls back if the folder doesn't exist yet?). How can I ensure that, having just installed PHP and pecl, my next pecl install will build extensions for the right flavor of PHP? 2. Why does php turn on thread-safety for mod_php at all on Linux, given that it apparently still doesn't work very well with various extensions in a genuinely multithreaded situation, slows things down, takes more memory, and leads to problems like this one? Everyone I've found runs PHP under the Apache prefork MPM, which does not attempt to run PHP in multiple threads of one process. I have never seen anyone successfully use the worker MPM with PHP, except by moving PHP out to a fastcgi process pool, which is, again, single-process PHP. Even Microsoft's PHP accelerator uses the fastcgi-based, one-process-per-PHP-request approach. Since Windows is so thread-oriented that seems significant. I have attached my script. Thanks for any insight! On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov <nikita....@googlemail.com> wrote: > Hi internals! > > I have written an RFC that proposes to *deprecate* and *remove* the /e > modifier: > > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier > > Comments welcome! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
update-php.sh
Description: Bourne shell script
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
