Custom Building PHP on Windows and Linux

At the encouragement of Elizabeth Smith, I went through the process (not-so-recently as of this blog entry) of compiling PHP on Windows. I actually managed to get 5.2.5 and 5.3 both working on Windows XP. Major credit for success in that endeavor goes to Elizabeth herself who helped me through hurdles in the process, her older tutorial on compiling PHP 5.2 on XP using VCE 2005, and Pádraic Brady's tutorial for compiling PHP 5.3 on Vista using VCE 2008.

First off, there are a few hefty things to download and install. Here's the laundry list.

Beyond the slight differences in the software required, the process described in Elizabeth's tutorial is still fairly accurate. One thing I noticed for 5.2.5 is that there's an issue with including IPv6 support, which is done by default when you configure your build. When you try to compile, you'll probably see an error that looks like this.

network.c(897): error C2065: 'in6addr_any': undeclared identifier
network.c(897): error C2440: '=' : cannot convert from 'int' to 
 'IN6_ADDR'

There are two ways to get around this. The first is to include the --disable-ipv6 flag in the configure line. The other is applying the changes in lines 94-96 of a fairly simple patch to your network.c file so that it includes these lines in the proper place.

#if HAVE_IPV6
const struct in6_addr in6addr_any = {0}; /* IN6ADDR_ANY_INIT; */
#endif

Another issue is that you may receive an error regarding libmysql.dll not being found when you attempt to run nmake test. You must have the directory containing this file either in your PATH or parallel to php5ts.dll, as these are the only places that Windows will look for it. Thanks again to Elizabeth for this tip.

OK, hopefully the Linux people haven't left yet. (You guys have a slightly more short and sweet segment in this blog entry.) I also did a custom build of 5.3 on Debian recently to use in running Phergie. I wanted to do a minimal local build to optimize performance (5.3 includes the garbage collection patch) as well as to include a few extensions that Phergie uses. One of these was the pspell extension for her Spellcheck plugin. I don't have root access to the system on which I was going to run her, and since it didn't have the aspell libraries already installed, I had to compile those from source as well. Here's how I did it.

First, aspell itself.

wget -c ftp://ftp.gnu.org/gnu/aspell/aspell-0.60.5.tar.gz
tar -zxvf aspell-0.60.5.tar.gz
cd aspell-0.60.5
/configure --prefix=/path/to/aspell-0.60.5/build
make
make install

Next, the English dictionary for aspell.

wget -c ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-6.0-0.tar.bz2
bunzip2 aspell6-en-6.0-0.tar.bz2
tar -xvf aspell6-en-6.0-0.tar
cd aspell6-en-6.0-0
./configure --vars ASPELL=/path/to/aspell-0.60.5/build/bin/aspell \
    PREZIP=/path/to/aspell-0.60.5/build/bin/prezip-bin
make
make install

And finally, PHP with the pspell extension compiled in.

wget -c http://snaps.php.net/php5.3-200803032330.tar.gz
tar -zxvf php5.3-200803032330.tar.gz
./configure --disable-cgi --without-sqlite --enable-pcntl \
     --prefix=/path/to/php-5.3/build/php_build \
     --with-pspell=/path/to/php-5.3/build/aspell-0.60.5/build
make
make test
make install

And presto, that's all there was to it.

March 8, 2008 | Filed under and | 1 Comment

The Yin and Yang of Typing

Without a little background in programming languages or computer science in general, it's entirely possible that typing systems are not something that have crossed your mind. I thought I'd take a blog entry to share some of my thoughts on how it's affecting the creation and evolution of languages.

First of all, Benjamin C. Pierce probably has a point: terminology used to refer to typing concepts is about as useful as buzzwords like AJAX or Web 2.0 these days. Be that as it may, I'm going to reach back into the recesses of what I recall from the programming languages course I took in college to recall some of this terminology.

If you aren't familiar with static versus dynamic typing or strong versus weak typing, it may be worth it to read up on those before proceeding with the rest of this blog entry. Here are a few examples of each:

  • Static/weak - C
  • Static/strong - Java
  • Dynamic/weak - PHP
  • Dynamic/strong - Python

The line between strong versus weak typing seems to be blurred as languages like these evolve. The reason for this is that each side of typing has its advantages. Strong typing allows for compile-time checking, which can serve to eliminate human error, as well as performance optimizations from being aware of types at compile-time. They can also serve to make source code more intuitive to follow in some respects. Weak typing, on the other hand, can allow for higher levels of abstraction and, by proxy, the need for less code in order to allow identical operations to be executed on multiple types. It can also allow for things like variable variables, variable functions, and other interesting features not possible in strongly-typed languages.

Yet languages on either side of the proverbial fence are drawing in strengths from the other side. Java, before limited to the flexibility that could be provided by polymorphism while still maintaining strong typing, introduced generics in 1.5, whereby typing was still enforced but a higher level of logic abstraction was enabled for developers. By the same token, PHP has had explicit typecasting for a while and more recently in 5.1 introduced type hinting for array and object types (which may extend to scalar types in later versions). C# in 3.5 adds type inferencing, which while it's only syntactic sugar at least alleviates the need for verbosity when performing the most common method of initialization (i.e. setting a variable of a given class to an object instance of that class, as opposed to one involving a subclass of one or more of the classes involved).

It's also becoming commonplace for dynamically typed language interpreters to get ported to Java and .NET in order to leverage the features of those languages and the native libraries of the host language in the existing execution environment. Take these examples for instance.

In short, some level of control over typing is obviously a desired feature in any useful language. As well, I don't think a language can be truly useful without having a bit of both worlds to some degree. The reason for the existence of programming languages is to enable developers to control machines whose primary purpose is to manipulate data (and, as has been pointed out many times before, are stupid and do what we tell them to do). If control over said manipulation is hampered by the typing system, it hampers the effectiveness of the language. In this, I have to agree with Ludwig Wittgenstein, who said, "The limits of my language mean the limits of my world."

January 19, 2008 | Filed under , , , , and | 1 Comment
Page:  1