This time I got to ask the lazyweb, or the Gentoo powerusers at least, some help for my tinderbox; with PHP and the PHP packages. As an introduction, since I know not all users understand what the tinderbox is and this time I’m asking all users, consider my tinderbox like the ultimate Gentoo system. It’s a simple chroot where as many packages as possible gets built, installed and merged, or at least it tries to.
Most of the problems found in the tinderbox are not really tinderbox-specific; they are generic failures with the latest compiler and glibc, or failures with the most recent version of a library, in a package that is rarely used; basically they are bugs that could be reported by anybody, but the tinderbox makes it easier to report them since I receive all of them in series.
In the recent weeks I started reporting test phase failures too; thanks to Portage’s test-fail-continue feature, I don’t need to skip over all the packages when their tests fails, like it would happen with just tests enabled normally, but it still takes time, and more than a couple of packages tend to freeze during test phases.
Unfortunately, I’m having some problems with the testing of some PHP PECL extensions: the only thing that the log says is the following:
>>> Test phase [test]: dev-php5/pecl-timezonedb-2008.8
make -j14 -j1 test
Build complete.
Don't forget to run 'make test'.
ERROR: Cannot run tests without CLI sapi.The obvious answer here is to make sure that the CLI (command line interface) version of PHP is built, but, well, it is! The cli USE flag on the PHP ebuild is enabled in the tinderbox, and yet the tests fail. I’ve asked Christian (hoffie) about this but his interest in PHP does not extend to PECL, and the rest of the PHP team seems to be missing in action.
If somebody has an idea on what the problem is here, I’d be very glad to hear about it.
Similarly, all, or almost all the PEAR-based packages fail to install in my tinderbox; I’ve opened a bug where you can find the details, although there aren’t many; the pear command ends up failing without any notice at all.
And of course this also means that if you’re interested in working on our PHP team, especially on the PEAR and PECL extensions, your help is very needed right now!
What’s the output of @php-config –php-sapis@ and @php-config –php-binary@ ?
Could it be the dom option enabled?There is a bug #43341 that seems to cover your problem to some content and where one of the persons got it to work only if he disabled dom.Just a thought which you could try.
@someone you seem to be on the right track:<typo:code>yamato ~ # php-config –php-sapisapache2handleryamato ~ # php-config –php-binaryNONE</typo:code>@Triztz I do have the xml USE flag enabled and that does enable the dom; trying now to disable that and see what happens!
Unfortunately, doesn’t seem like dom is the culprit 🙁
Looks like pecl packages use php-config to find location of php executable. I have php built with cli and apache SAPIs and on my system
php-config --php-binaryalso gives NONE. I think the problem is with the way PHP is built. I have only experience with building it with cli and apache2 SAPIs. In such case PHP is built in two stages – I think to allow separate configuration directories (/etc/php/apache2-ph5 and /etc/php/cli-php5) per each one (maybe there are other reasons – I don’t know). First cli SAPI is built – with only cli SAPI enabled. During configure stage php-config script is generated. Once building cli is done, PHP is built with only apache SAPI enabled – at this point ./configure is run again in source folder and overwrites previously generated php-config. As it is being configured with apache SAPI only – that’s what eventually ends up in final php-config losing all information about existing cli build. If you look at installed /usr/bin/php-config you can see ‘–disable-cli’ in configure options (as this was passed to last configure pass). Basically only information about last built sapi and its ./configure options is saved.There is an experimental ‘fastbuild’ flag which builds both cli and apache sapi with only one run of ./configure script (and by using some sed and patching build system of php, you will still have separate config dirs) – therefore it seems that it would solve the problem with overwritten / incomplete php-config though I haven’t tested it myself.I’m not 100% sure if all of the above is correct. Also no idea how to solve the problem 🙁 (apart from using fastbuild flag).