On Tue, Jul 12, 2011 at 1:47 PM, Sam Nelson <samn at consistentstate.com> wrote:
> Wait, what?  I actually removed new_pgsql before I ran that last time.
> ...
> Okay, that was weird.

That combination of events isn't too surprising.

What is regrettably unfortunate about autoconf is that it tries really
rather hard to find default values, and if you have multiple
installations of PostgreSQL on your system, it is regrettably easy for
it to find the worng one, with the results that you observed.

In the "bad old days," the autoconfigure code for Slony was less
intelligent, and anyone doing a build would have to grovel through
their system's configuration to figure out how to set
--with-pgbindir=..., --with-pgincludedir=..., and a cast of a bunch
more.

Now, you "merely" need to specify --with-pgconfigdir, which commonly
captures all of the others successfully, making use of pg_config.  I
expect that if you had set that, the other things would have fallen
into place with less pain.  Unfortunately, if your $PATH has one or
more instances of pg_config lying around, they may get drawn into
service, worsening the configuration of the build :-(

I daresay that I haven't used the --with-pg[individualdirs] since we
added --with-pgconfigdir back in ~1.1.  pg_config is the Much Better
Mechanism for capturing what's needed.