4

I'm upgrading php on my server but I'm running into a problem with phpize and compiling external modules. phpize -v reports:

Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20090115
Zend Extension Api No:   220090115

But on my test server (which I'm trying to replicate) I get this:

Configuring for:
PHP Api Version:         20090626
Zend Module Api No:      20090626
Zend Extension Api No:   220090626

I'm running debian squeeze, pulling the php 5.3.0-2 packages from the experimental repo. The difference betweent he two servers is that the first server has had old verisons of php on it, and the test server was installed with php 5.3.0-2 from the start.

I've attempted uninstalling all PHP packages from the first server (using --purge to get rid of all the config files) and re-installing 5.3 fresh, but I'm still having the same issue. Help!

3 Answers 3

9

Solved this one on my own -- installing php5-dev 5.3 gives you a phpize AND a phpize5. phpize5 has all the newest APIs. I'd still love to know how to get the default phpize to have that, though -- at least, without symlinking.

4

How:

phpize is a simple shell script and you can peer into what it is doing. When called with --version it does this. I've snipped out quite a bit for brevity.

prefix='/usr/lib/php5'
includedir="`eval echo ${prefix}/include`/php"
SED="/bin/sed"
..
PHP_API_VERSION=`grep '#define PHP_API_VERSION' $includedir/main/php.h|$SED 's/#define PHP_API_VERSION//'`
ZEND_MODULE_API_NO=`grep '#define ZEND_MODULE_API_NO' $includedir/Zend/zend_modules.h|$SED 's/#define ZEND_MODULE_API_NO//'`
ZEND_EXTENSION_API_NO=`grep '#define ZEND_EXTENSION_API_NO' $includedir/Zend/zend_extensions.h|$SED 's/#define ZEND_EXTENSION_API_NO//'`
..
echo "PHP Api Version:        "$PHP_API_VERSION
echo "Zend Module Api No:     "$ZEND_MODULE_API_NO
echo "Zend Extension Api No:  "$ZEND_EXTENSION_API_NO

The prefix variable at the top is hardset when PHP is compiled. /usr/lib/php5 is where my installation for that machine is. All phpize does is look at the header files for the installation at that prefix. I imagine that your phpize5 has a completely different path to phpize.

Why:

Perhaps your installation wants to differentiate between the older and newer versions, so has renamed one of them. It could be a result of having a 4.x release previously installed on the same machine.

0

This should be a comment but I can't find the comment link. It's actually a response to the previous answer.

So am I to take it that the phpize file is custom built for your system as a side effect of compiling PHP? Maybe the mac ports procedure that I used pulled in a precompiled binary and that's why I don't have phpize5. I don't really know how that works. But what you're implying is that if you hack on your phpize and make it point to a newer installation of PHP that it will pull the correct API #'s to match? Ack there's a lot of stuff to change in there! I'd rather have a program do it that would ask you questions about where stuff is so you'd be sure and change everything that needs changing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .