Postgres (pg gem) compilation problems on OpenSolaris

A word to the wise: pg 0.10.0 doesn’t want to compile on OpenSolaris.

The Stack

One of our production servers is running OpenSolaris version OpenSolaris 2008.11 snv_101b_rc2 X86, Ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-solaris2.11], and PostgreSQL 8.3.4. We use Capistrano for deployment with some bundler goodness thrown in the mix.

The Problem

Here’s what we see when bundler tries to build the gem:

ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/usr/local/rubies/ruby-1.8.7-p302/bin/ruby extconf.rb
checking for pg_config... yes
checking for libpq-fe.h... yes
checking for libpq/libpq-fs.h... yes
checking for PQconnectdb() in -lpq... no
checking for PQconnectdb() in -llibpq... no
checking for PQconnectdb() in -lms/libpq... no
Can't find the PostgreSQL client library (libpq)
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/usr/local/rubies/ruby-1.8.7-p302/bin/ruby
        --with-pg
        --without-pg
        --with-pg-config
        --without-pg-config
        --with-pg-dir
        --without-pg-dir
        --with-pg-include
        --without-pg-include=${pg-dir}/include
        --with-pg-lib
        --without-pg-lib=${pg-dir}/lib
        --with-pqlib
        --without-pqlib
        --with-libpqlib
        --without-libpqlib
        --with-ms/libpqlib
        --without-ms/libpqlib

Oh yeah! Good stuff right there.

The Investigation

At first, I thought the problems were to do with the development libraries being missing. This is frequently the case, and the error message pretty much says just that. Wrong – libpq was (and is) present. In fact, prior to the pg gem, we had the postgres gem running and it had the same dependencies. Next up: must be a mixup in the deployment situation. Not so. Capistrano and bundler both checked out okay.

After my searches on The Google provided ample proof that compilation on a Solaris box can be tricky, my next suspect was a wonky compiler toolchain. Nope, toolchain was just fine. Heck, I even checked the rbconfig.rb to make sure. That’s right, I’m thorough.

The (Temporary) Solution

On a lark, and after a day of trying all kinds of weird little tweaks … I figured, what about 0.9 ??? A quick look through the commits on 0.10.0 showed some recent work on the build system. Why not? Quick, change the Gemfile:

source 'http://rubygems.org'

gem 'rails', '3.0.3'
gem 'pg', '~> 0.9.0'

# That '~>' operator tells Bundler/Rubygems to allow gem updates to
# the least significant portion of the version number for that gem. 

# In the Gemfile snippet above, I am signifying that I will allow any pg version
# in the 0.9.x branch. Had I specified '~> 0.9', bundler would install
# the newest pg gem with a major version of '0.'.

Then

  > bundle install
  > git add .
  > git commit -m "Attempt to use pg 0.9"
  > git push
  > cap deploy

SUCCESS!

I just opened this issue on the pg project and will update this space when we come up with a solution. For now, just install the pg gem from the 0.9.x version.

Epilogue

You might be wondering why I would care if I’m running this particular gem for Postgres connectivity. There are three postgres gems out there that I know of: pg, postgres, and postgres-pr. Let’s take a look at some stats from rubygems.org:

gem                 version             date            downloads
----------------    -----------------   -------------   ----------
postgres (native)   0.7.9.2008.01.28    Jan 28, 2008          49K
postgres-pr (ruby)  0.6.3               Dec 14, 2009          35K
pg (native)         0.10.0              Dec 01, 2010         210K

Even taking the subjective versioning and download numbers, I want us to use a library that is actively maintained and well used. Michael Granger is all over pg and having the most downloads by far, gives me the warm fuzzy that errors will have been encountered and (hopefully) fixed. Since we run on a platform that can use the native gems, pg is the obvious choice – for us. Of course, as they say, your mileage may vary.

UPDATE Dec. 15, 2010:

The issue has been updated – looks like this isn’t an isolated problem.