The libdbi library provides a feature for C programmers that has long been missing. The interface is clean and the framework for adding new drivers is relatively straightforward.
libdbi brings to the UNIX C/C++ developer a functionality that has long been available to other programmers. A single binary may now be made database independent, without a tedious ODBC installation.
Windows programmers have long been able to free themselves from the bonds of a single database by using ODBC. With the porting of ODBC to UNIX, and the adoption of OS X (UNIX in six colors) by Apple, database independence becomes available to nearly all application developers.
That's the theory, at least. Unfortunately, configuring ODBC requires administrative privileges, and configuration is decidedly non-trivial. If you're like me, and most of the applications you write are written to be run in a web hosting environment, you can count on not having administrative access to the server.
Installing
At the time of this writing, libdbi supports PostgreSQL, MySQL, SQLite, mSQL and Oracle databases. The very first prerequisite is that you must install the client libraries for every database engine that you want to make available. In my case I installed PostgreSQL, MySQL and SQLite, the three database engines which I use the most.
libdbi comes in two parts. The first, libdbi, provides the basic library that you'll link your programs against. It contains the framework that figures out which functions to call in the database client libraries. You can download it from: http://libdbi.sourceforge.net
The second part is libdbi-drivers. This package builds to shared objects, one for each database, which in turn link to their respective database client libraries. This package can be downloaded from: http://libdbi-drivers.sourceforge.net
libdbi must be configured and installed first. It's a fairly straightforward affair. All of the options are standard configure, except for the --with-ltdl and --with-shlib-ext options. If your system has a problem with the dlopen function call (which you won't know until you've tried to run a libdbi program), you'll need to enable the --with-ltdl flag, which uses a dlopen call provided by libtool. If you want the drivers to have an extension besides the default of .so, you'll need to specify that with the --with-shlib-ext option.
Installing libdbi-drivers
libdbi-drivers is a little more interesting to install. You must explicitly tell configure which drivers you want to include using the usual round of --with-driver flags. Every UNIX distribution seems to install these drivers in slightly different places though, so some special flags have been provided. My OpenBSD machine, for instance, places its PostgreSQL includes under /usr/local/include/postgresql and the client libraries in /usr/local/lib. The --with-driver-incdir and --with-driver-libdir options let you specify the locations of includes and client libraries if that is necessary. Generally the configure script is smart enough to look under both the /usr and /usr/local directory trees, and this kind of complication isn't usually needed.
In the current pre-1.0 version of the driver distribution, there is an undocumented step which you must take. The libraries are installed in /usr/local/lib/dbd, with the full version number as part of the file extension, just as other shared libraries use. You'll need to create links in that folder ending in the .so file extension and pointing to the actual libraries.
In case you haven't realized it, this all means that you've got a lot of shared libraries kicking around. Rather than just the necessary client libraries, you now also have all of the shared objects for the libdbi drivers, as well as the libdbi library itself. It's a viable tradeoff, but it's easy to see how problems could develop down the road.
