Sunny Days – Day 5

This day saw my next attempt at installing PHP. This time I tried to compile the libraries needed manually. Before I go into the details, let me tell you how I organized the directory layout. Where I can, I use a fixed directory layout when compiling stuff. It looks like this:

/root
   +----/soft
         cfg-<pkg-name1>
         cfg-<pkg-name2>
         ...
           +----/package1
           +----/package2
         ...
           +----/tarballs
                 package1.tar.bz2
                 package2.tar.gz
                 ...

The files named cfg-<pkg-nameX> contain specific instructions for those packages where any overriding of the default configuration options is neccessary. The format is standardized and looks like this:

#!/bin/bash
cd <pkg-directory>
if [ -f config.cache ]; then
  rm config.cache -f
  make clean
fi
./configure \
    --whatever-option=whatever-parameter \
    ...

Note that there’s no make command at the end of these files. I like to see the output first and if it’s ok, I run make (or, for we are on Solaris 10, gmake) manually.

So everytime I need to build a library or tool, I download the source package into /root/soft/tarballs, change to /root/soft and unpack the file using „gtar xvzf tarballs/<package_name&gt”. Then I check whether I need a configuration file by changing to the package’s directory and using „./configure –help”. If some configuration is needed, I create a cfg-<abbrev._pkgname> file. This helps me to easily find the options I used, should I need them later.

Prerequisites
Since my PHP configuration is somewhat bloated, I needed some extra packages before I could actually compile PHP. As stated yesterday, I failed using the packages provided by BlastWave. This quite possibly wasn’t BlastWave’s fault as it turned out, but more on that later.

There were two prerequisites that definitely had to be met. First, I needed support for Berkeley DB 4 because I have some sites using that database format I want to migrate if time permits. Second, I needed the MySQLi interface provided by newer MySQL versions. That’s because only MySQLi supports compressed transfers, thus reducing bandwith consumption dramatically when accessing external MySQL servers over the internet.

As it happened, exactly those two were the major stumbling blocks. While I was able to download, compile and install all other needed components just fine, those two really gave me headaches. So I will explain their installation in a bit more detail.

Berkeley DB 4.4.20
To install Berkeley DB and it’s libraries, I downloaded the source tarball from Sleepycat. I also downloaded the available patches one and two. The chain of commands used:

# cd /root/soft/tarballs
# wget ftp://ftp.sleepycat.com/releases/db-4.4.20.tar.gz
# wget http://www.sleepycat.com/update/4.4.20/patch.4.4.20.1
# wget http://www.sleepycat.com/update/4.4.20/patch.4.4.20.2
# cd ..
# gtar xvzf tarballs/db-4.4.20.tar.gz
# cd db-4.4.20
# patch -p0 < ../tarballs/patch.4.4.20.1
# patch -p0 < ../tarballs/patch.4.4.20.2
# cd build_unix
# ../dist/configure
# gmake install

This installed the Berkeley DB files in /usr/local/BerkeleyDB.4.4/… which was just fine with me. However, that wasn’t fine with PHP. While the confiure script ran just fine, the following gmake would complain about not being able to find libdb-4.4.

To make that very clear: The reason for that is PHP’s totally braindead handling of additional include and library pathes. Although I told it where to look for the libs it just choose to ignore the additional pathes specified and drop them from list of pathes to pass to the linker.

To fix this, I had to create symbolic links in /usr/local/lib pointing to the actual library:

# cd /usr/local/lib
# ln -s /usr/local/BerkeleyDB.4.4/lib/libdb-4.4.so
# ln -s /usr/local/BerkeleyDB.4.4/lib/libdb4.so

This helped PHP to finally find the libraries and compile Berkeley DB support.

MySQL
With MySQL it was a different story. Actually, there is a complete version of MySQL shipping with Solaris 10. Unfortunately this version is quite outdated and thus doesn’t contain the code needed to support MySQLi and, for that matter, compressed transfers.

My first try to solve this problem was to download the premade packages for Solaris 10 from the MySQL website and use them to compile PHP. In short: Don’t. While PHP’s configure script will run without a hitch, compilation will fail because of unresolved symbols in the libraries supplied my MySQL. Mainly that’s because those libs are linked against their own version of Z-Lib, but I didn’t investigate that further.

So that left me with the options of either compiling MySQL by hand or trying to get the BlastWave version to cooperate with PHP. I chose the latter approach and downloaded just the development packages:

# pkg-get -i mysql5devel

This will also add the runtime package mysql5rt to your system. I then checked with ldd whether the MySQL libararies from BlastWave would rely on any external libs which they didn’t. Next I changed the configuration statement for PHP in my config script:

./configure \
...
--with-mysql=shared,/opt/csw/mysql5 \
--with-mysqli=shared,/opt/csw/mysql5/bin/mysql_config \
...

mhash 0.9.6
Lest I forget it, there was another little tweak I had to make. mhash 0.9.6 wouldn’t compile out of the box. It kept complaining about the constants ‘false’ and ‘true’ not being defined but used. I fixed this rather crudely by editing ./includes/mutils/mutils.h where I replaced the ‘false’ in the definition for MUTILS_FALSE with a 0 (that’s a zero) and the ‘true’ for MUTILS_TRUE with a -1.

Running PHP, finally
After these changes PHP not only configured itself just fine but also compiled without any error messages. With the final „gmake install” it installed all components and even added the line

LoadModule php5_module  libexec/libphp5.so

to the Apache configuration in /etc/apache2/httpd.conf. It didn’t, however, add the type definition so that Apache would know ho to handle files with a .php extension. This I added manually to /etc/apache2/httpd.conf:

AddType  application/x-httpd-php .php

All that was left to do was to restart Apache using „svcadm restart apache2”. A final test showed that phpinfo() displayed just fine. Since I had some other pressing work to do, I left it at that for the moment.

In case you’re interested, you’ll find the list of packages I compiled as well as some notes and also my configuration scripts here.

Lessons learned

[ All posts about my experiences with the SunFire T2000 >>> ]

Incoming search terms:

• readynas mysqli