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.

Comments 4

  1. Post
    Author

    Hi Dave!

    I had read that problem on eggheadcafe the other day, it is pretty much a step-by-step manual on how to install, just interspersed with the OP saying “It doesn’t work, now what?!?!?”.

    Yeah, libpq is actually there, as demonstrated by the successful compilation and installation of pg 0.9.0 (it has the same dependencies).

    I should mention that before trying to use pg, we had the postgres gem (0.7.9.2008.01.28) running on this server and as near as I can tell, it requires the same libraries.

    I have updated the post to reflect this information.

    Thanks for the comment.

  2. David: I don’t think the header is the problem; I think it’s that the extension config assumes that Ruby and PostgreSQL were built with the same compiler. 0.10.1 fixes this assumption.

    Don: I’ve updated the ticket, and uploaded a prerelease of 0.10.1. If you could try it out at your convenience, I’d appreciate it.

Leave a Reply

Your email address will not be published. Required fields are marked *