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:

 /Applications/MAMP/bin/php/php5.3.6/bin/pecl  install ibm_db2

The next issue was caused by a crufty pear.conf:
Notice: unserialize(): Error at offset 267 of 1133 bytes in Config.php on line 1050; ERROR: The default config file is not a valid config file or is corrupted.

So removing pear.conf fixed it.
 mv /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf.orig

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:
[09-Jan-2012 15:03:14] PHP Warning:  PHP Startup: Unable to load dynamic library '/Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ibm_db2.so' - dlopen(/Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ibm_db2.so, 9): no suitable image found.  Did find: /Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ibm_db2.so: mach-o, but wrong architecture in Unknown on line 0

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:
file /Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ibm_db2.so /Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ibm_db2.so: Mach-O 64-bit bundle x86_64 file /Applications/MAMP/bin/php/php5.3.6/bin/php /Applications/MAMP/bin/php/php5.3.6/bin/php: Mach-O executable i386


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:
/Applications/MAMP/bin/php/php5.3.6/bin/pecl download ibm_db2 /Applications/MAMP/bin/php/php5.3.6/bin/phpize MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS="-arch i386  -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch i386  -g -Os -pipe" CXXFLAGS="-arch i386  -g -Os -pipe" LDFLAGS="-arch i386  -bind_at_load" export CFLAGS CXXFLAGS LDFLAGS CCFLAGS MACOSX_DEPLOYMENT_TARGET ./configure --with-php-config=/Applications/MAMP/bin/php/php5.3.6/bin/php-config --with-IBM_DB2=/Users/suzyq/sqllib make make 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:
Saved crash report for httpd[71530] version ??? (???) to /Users/suzyq/Library/Logs/DiagnosticReports/httpd_2012-01-09-160207_Suzy-Deffeyess-MacBook-Pro.crash

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:
IBM_DB2_SHARED_LIBADD = -Wl,-rpath,/Users/suzyq/sqllib/lib64/ -L/Users/suzyq/sqllib/lib64/ -ldb2

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:
[ibm_db2] ibm_db2.instance_name=suzyq

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....


$database = 'mydbname'; $user = 'db2inst1'; $password = 'xxxxxxxxxx'; $hostname = 'myhost.mydomainname.com'; $port = 50000; $conn_string = "DATABASE=$database;" .   "HOSTNAME=$hostname;PORT=$port;PROTOCOL=TCPIP;UID=$user;PWD=$password;"; $conn = db2_connect($conn_string,'',''); if ($conn) { echo "Connection succeeded."; db2_close($conn); } else { echo "\n Connection failed."; print "CONN_ERROR value: " . db2_conn_error(); print "ERRORMSG : ".db2_conn_errormsg(); }

The power of creation.....errr.... Programming

I recently took phonegap for a spin around the block. I've found that I learn best by flinging myself at something and doing/creating/making something. Phonegap is pretty cool. It creates platform independent hybrid apps for mobile devices. It basically uses JavaScript as its programming language, and provides APIs for using all the sensors on your device. That means you can use whatever JavaScript libraries you want, and you can compile your app for android, iphone, and blackberry.

One of my pain points in developing augmented reality apps has been that getting camera access meant developing a native app, which in turn meant porting waz painful. Granted, I think for vision based AR, a true native app is still the way to go because you usually need to do some crunching on images that you grab from the camera. But once video support is added to phonegap, things get really interesting for location based AR.

Anyway, I created a simple phonegap app that grabbed a picture from my camera, displayed it in the app, and then used jquery to push it to my waiting php script on my server. I learned a lot from it, and was struck by one thing. I realized that in the space of an afternoon that I had sort of implemented a rough cut version of what my Eyefi setup does. My Eyefi pushes images from my camera to my NAS, and the phonegap app does a similar thing, using all open source. Open source is so cool that way. It's like no matter what I need, there is always a waiting set of open source power tools for the task.