Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

  1. What does no-debug-non-zts-20090626 even mean, and why is it the default?

  2. 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/ lines to my .ini files.

  3. Is there ever a risk when compiling a new module, that it will go in a different directory than the directory in question #1?

share|improve this question
up vote 2 down vote accepted

"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.

share|improve this answer
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
Accepting this answer as it directly answered my initial questions. Thanks. – Mike Purcell Apr 25 '13 at 16:30

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

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

Anyway, got it to work.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.