I’m a web developer and unlike a lot of developers I have been a big fan and user of Internet Explorer 7 and now version 8.

However the standards compliance of Internet Explorer has always left something to be desired.  With the introduction of 7 a few years back the job of making sites work in Internet Explorer became a whole lot easier, but there is still a lot missing that really ought to be included, and thank goodness transparent PNG support was added.

Recently I switched to using Internet Explorer 8 RC as my main browser and whilst I like it there were a number of failings I found.  The first is the so-called standards compliance.  Well seeing as it doesn’t support lots of CSS 3 properties doesn’t really make it standards compliant, but I digress. Mainly my issues were with it’s rendering of pages that looked great in Firefox, Chrome, Opera and Safari but just didn’t work properly in Internet Explorer 8.  The sites weren’t even using browser sniffing to load different stylesheets.  Quite simply IE’s implementation of the standards was different to all the other major browsers.  Sorry Microsoft, must try harder!

Over the past month or so I’ve suddenly discovered that I now use Firefox 3 as my primary browser at work (I still use Safari 4 at home as I’m a mac person) and combine it with Firebug and it’s simply stunning.

What actually prompted me to write about this was a story I picked up upon this morning entitled ‘IE8 May Be End of the Line For Internet Explorer‘.  It discusses the fact that Microsoft might be considering using Webkit (the engine behind Chrome and Safari) for Internet Explorer. In an article on AppleInsider Steve Ballmer is quoted as saying

Addressing a developer conference in Sydney Australia, Microsoft CEO Steve Ballmer said the idea of using WebKit as the rendering engine within its web browser was “interesting” and added “we may look at that.”

The fact that Ballmer would even mention using WebKit is very interesting indeed as you’d expect such a thing to be dismissed out of hand.  WebKit quite simply has the fastest and best rendering engine of any modern browser.  Just try Safari 4 on Windows or a Mac to try it out for yourself

OK let me first start by saying, I absolutely love PHP, I tend to compile my PHP from source and for the most part have absolutely no issues with it whatsoever.

Now for work I needed to install PDO extensions to PHP with Microsoft SQL Server support (PDO_DBLIB). I shall also start off by saying that I currently use the standard sqlite extensions to PHP.

Now PDO is actually available on Linux as pdo.so in the modules directory usually by default so let’s actually just try to run

pecl install pdo_dblib

Can’t do that we get the error

“pear/PDO_DBLIB requires PHP extension “pdo” (version >= 1.0)”

OK well we had PDO installed but clearly the wrong version.  First up I recompiled PHP adding in the following configuration lines

–with-zlib –enable-pdo=shared –with-pdo-sqlite=shared –with-sqlite=shared

I actually already had zlib compiled, I just reference it here as it’s required. That all worked great, without errors.  So now let’s run

pecl install pdo

we should get the right version, correct?  No we still get the same error.  This led me to the following bug report.  Note that this bug was opened in May 2006 and is still unsolved at the time of writing.  What we have to do is manually download the package, edit package.xml and remove the PDO dependency line.  Install as usual and restart apache!

These are the steps that work

pecl download pdo_dblib

This will download a tar ball of the extension. Extract the tar ball.

tar -xzvf PDO_DBLIB-*.tgz

That will uncompress the package in to a standalone file, package.xml
and a folder containing the extension, in my case it was, PDO_DBLIB-X.X.
Where X was the version number. Open package.xml using your favourite
command line editor. Find and remove the line,

<dep type=”ext” rel=”ge” version=”1.0″>pdo</dep>

Save the package.xml file, and move it in to the PDO_DBLIB directory.

mv package.xml ./PDO_DBLIB-X.X

Navigate to the PDO_DBLIB directory, then install the package from the
directory. You may need root access for this step.

cd ./PDO_DBLIB-XX

pecl install package.xml

After editing php.ini to load

extension=pdo.so
extension=pdo_dblib.so

phpinfo() reported that the DBLib driver was available as was PDO, all was great. Now I tried to run sqlite_open and it refused to work.

I thought maybe it was the pdo sqlite extension that was conflicting, as I don’t actually use the pdo version of sqlite, just the main function library I decided to reconfigure php without the sqlite options.

Then I get an error saying that I had configured PDO as a shared object but sqlite was static.  Hmm the PHP manual tells me something different though and I quote

In PHP 5, the SQLite extension and the engine itself are bundled and compiled by default. However, since PHP 5.1.0 you need to manually activate the extension in php.ini (because it is now bundled as shared). Moreover, since PHP 5.1.0 SQLite depends on PDO it must be enabled too, by adding the following lines to php.ini (in order):

So this is telling me that SQLite is enabled by default and is installed as shared.  Well the PHP installer just told me different, that it’s installed by default but as static!

OK so back to configure PHP again but this time with the sqlite shared options.  Then we’ll reference sqlite.so in the php.ini extensions and restart apache!

Oh no we can’t load apache because the version of sqlite.so is incompatible with the version we need for pdo_dblib.so.

Let us run

pecl install sqlite

Running that gives us the following error

tmp/tmp8laqB1/SQLite-1.0.3/sqlite.c:125: warning: initialization from
incompatible pointer type
/tmp/tmp8laqB1/SQLite-1.0.3/sqlite.c:126: warning: initialization from
incompatible pointer type
*** Error code 1
make: Fatal error: Command failed for target `sqlite.lo’
ERROR: `make’ failed

The PHP bug report at http://pecl.php.net/bugs/bug.php?id=8181 that was opened in July 2006 tells us this has all been fixed, but with numerous responses telling the developers that it’s still broken.  At the time of writing, this is still broken!

This then leads me to the following fix

$ pear download sqlite
then unpacked and began to compile it
$ tar zxvf SQLite-1.0.3.tgz
$ cd SQLite-1.0.3
$ phpize
$ ./configure
$ make

edit sqlite.c, comment out the following line:
/* static unsigned char arg3_force_ref[] = {3, BYREF_NONE, BYREF_NONE, BYREF_FORCE }; */

And then change these lines
function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, arg3_force_ref)
PHP_FE(sqlite_popen, arg3_force_ref)
to:
function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, third_arg_force_ref)
PHP_FE(sqlite_popen, third_arg_force_ref)

$ make
$ make install
$ cp modules/sqlite.so /usr/lib/php/modules
$ /sbin/service/httpd restart

Why oh why do I have to edit the c source code to get this working?   Which by the way DOES actually fix the problem and now I have PDO, SQLite and PDO_DBLIB working on the same system.

This is why I’m starting to loose faith in the open source PHP community, not because they do a great job in the first place, but because bugs like this exist for well over 2 years!

The response from the Open Source community will be, fix it yourself.  That simply isn’t the point, I’m not a C developer, nor do I have the inclination to be.  I also do not know the inner C workings of PHP to easily fix these issues.

I’ve just wasted two days of my life researching, testing, debugging PHP extensions, I hope it helps anyone else with these issues!