Building Statically

In the list of loaded modules, you probably noticed that several modules were listed that were not included using the extension directive in php.ini. These modules are built directly into PHP and are compiled as part of the main build process.

Building Static Under *nix

At this point, if you tried navigating up a couple directories to the PHP source tree root, you could run ./configurehelp and see that although your sample extension is located in the ext/ directory along with all the other modules, it's not listed as an option. This is because, at the time that the ./configure script was generated, your extension was unknown. To regenerate ./configure and have it locate your new extension all you need to do is issue one command:

$ ./buildconf

Note

If you're using a production release of PHP to do development against, you'll find that ./buildconf by itself doesn't actually work. In this case you'll need to issue: ./buildconf force to bypass some minor protection built into the ./configure command.

Now you can issue ./configure help and see that enable-sample is an available option. From here, you could re-issue ./configure with all the options you used in the main PHP build plus enable-sample to create a single, ready-to-go binary containing a full PHP interpreter and your custom extension.

Of course, it's probably a bit early to be doing that. Your extension still needs to do something besides take up space. Let's stick to building a nice lean shared object for now.

Building Statically Under Windows

Regenerating the configure.js script for Windows follows the same pattern as regenerating the ./configure script for *nix. Navigate to the root of the PHP source tree and reissue buildconf.bat as you did in Chapter 4.

The PHP build system will scan for config.w32 files, including the one you just made for ext/sample, and generate a new configure.js script with which to build a static php binary.