Tuesday, January 10, 2012

IBM_DB2 PHP extension on Mac with MAMP


I recently worked through all the pain and suffering to get the ibm_db2 php extension working on MAMP on my Mac running Snow Leopard. It wasn't easy, and if you are struggling through the same thing, I wrote this post for you. My next step now that I have the php extension working is to see if it will work with Symfony2, since IBM DB2 support was added to the base of Doctrine2.

The only DB2 for Mac is the beta for 9.5. I didn't want the full blown db2 installed on my OSX machine, I only wanted the headers and libraries required to build the php extension. There was a separate 'Remote Tools' download that contained client type db2 stuff, including headers and libs. It's on the same download page as the full package after you log in with your free IBM id.

After installing (as non root user) in a path without spaces, I tried the straightforward pecl install. Note the path info, otherwise it will try to build the extension for the php that ships with OSX (/usr/bin/php) instead of the one in the MAMP install directory:



The next issue was caused by a crufty pear.conf:


So removing pear.conf fixed it.


The next issue was that the MAMP default install no longer includes the php source, so it complained about not finding php.h when I did the pecl install. I resolved this by downloading the MAMP source code and grabbing the php 5.3.6 source bundle. Since it was complaining about not finding /Applications/MAMP/bin/php/php5.3.6/include/php/main/php.h , I made an include directory under php5.3.6, and untared the php source there, and renamed the directory to match what pecl was seeking.

The extension then built, and was in the right spot, and I added  "extension=ibm_db2.so" to the MAMP php.ini (make sure you find the right php.ini).

I then coded up a test php file to try the db2_connect command. No love yet, the ibm_db2 extension wasn't even loading properly. This error popped up in my MAMP php error log:


That last line and a fair amount of googling indicated that it was probably a 32 vs 64 bit thing. I confirmed it by using 'file' on both php executable, and on the ibm_db2 library i had just built:



So I needed to rebuild the ibm_db2 extension for 32 bit by hand, since pecl was doing 64 bit. In retrospec, maybe the fact that my sqllib/lib is actually a symbolic link to lib64 is why this happened, and maybe there was some way to make pecl do it's thing 32 bit. But I didn't realize this til later, so I rebuilt by hand.

I created a new directory for the pecl extension (location of dir not important), and downloaded the pecl extension, set some compiler flags, and did the build. Note the specification of the --with-IBM_DB2 pointing to my DB2 client directory install:


At this point the ibm_db2 extension loaded (yay!). I now wanted to try my simple test of connecting again. When I tried, the browser gave me a 404. Nothing in the http log or php error log. But I found this in /var/syslog/system.log:


Opening that showed that it could not resolve  _SQLAllocHandle. At this point I realized that  my sqllib/lib is actually a symbolic link to lib64. I noticed that even with all my fancy stuff in the compile flag step above, the Makefile still was pointing to sqllib/lib64 (verified the so was mucked up by doing: otool -L ibm_db2.so ). At this point I coulld have changed the symbolic link, but instead I changed one line in the Makefile, and repeated the make steps.
In Makefile, I changed this line to be lib32 in both spots:


One other change I made, that I wasn't sure was needed was putting this in my php.ini. Since MAMP wasn't sourcing the db2profile in /Users/suzyq/sqllib, I added this:


That got me to a ibm_db2 php extension that loaded, and eventually I got the right incantation of db2_connect(), and connected. Whew!


The simple connect.php test....