PHP - Extensions - no-debug-non-zts-xxxxxxxx

Question

I am compiling php extensions (memcached and xdebug), and when I run make install, they keep getting installed into /usr/local/php/lib/php/extensions/no-debug-non-zts-20090626. So a few questions:

What does no-debug-non-zts-20090626 even mean, and why is it the default?
Is it good practice to edit the php.ini file and set the extension_dir directive to the aforementioned directory? Or should I compile each module with a PREFIX=/usr/local/php/extensions? So when I do make install, they are put into a custom extensions directory, then I can add extension=/usr/local/php/extensions/memcached.so lines to my .ini files.
Is there ever a risk when compiling a new module, that it will go in a different directory than the directory in question #1?

score 3 · Accepted Answer · answered Jun 15 '12 at 22:58

3

"no-debug-non-zts-20090626" means that it's built without the debug flag, and without ZTS, which is the acronym PHP uses to indicate internal thread saftey. The datestamp is used to identify the internal API version. I'm pretty sure that one identifies PHP 5.3.

Instead of compiling these yourself and thus causing these questions to need answers, you probably want to really look for precompiled versions of these modules provided by your OS distribution or a trusted third party. Memcached and xdebug are amazingly common extensions, and chances are that they're already easily available to you.

Failing that, you probably want to use the pecl tool to download, compile and install these for you. These tools exist for good reasons.

answered Jun 15 '12 at 22:58

Charles

1,194
2
12
22

I see, so if I flip debug and zts flags and recompile php, then phpize memcached, upon make install of memcached, it will be installed into debug-zts-20090626? – Mike Purcell Jun 15 '12 at 23:00
Quite possibly, yes. – Charles Jun 15 '12 at 23:45
You were right about the 20090626 part, it matches the same date for `PHP Api Version` when I do a phpize. – Mike Purcell Jun 15 '12 at 23:57

score 2 · Answer 2 · answered Jun 20 '12 at 23:34

Ended up not custom configuring the location of the module, instead I just created extension .ini files which each load the extension using the full module uri:

; memcached.ini
extension=/path/to/php/lib/php/extensions/no-debug-non-zts-20090626/memcached.so

This way, when I do make install, I don't have to do any symlinking etc.

One a sidenote, If I don't use the full module uri within the custom .ini file, then PHP cannot find the module, which is odd because if I add the following to php.ini, it works fine:

; php.ini
extension=memcached.so

Anyway, got it to work.

score 0 · Answer 3 · edited Jul 26 '17 at 11:19

Check if libraries are found:

ldd /usr/lib/php/extensions/no-debug-non-zts-xxxxxxxx/memcached.so

Outbuildings:

yum -y install gcc make automake autoconf gcc-c++ flex bison
yum remove libmemcached
/usr/bin/pecl uninstall memcached
wget https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz
tar -xvzf libmemcached-1.0.18.tar.gz
cd libmemcached-1.0.18
./configure
make && make install
/usr/bin/pecl install memcached-2.2.0
echo "extension=memcached.so" >/etc/php.d/memcached.ini
service httpd restart
/usr/bin/php -i | grep memcached
echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php

Check logs:

tail -f /var/log/httpd/error_log

PHP - Extensions - no-debug-non-zts-xxxxxxxx

3 Answers3