On Fri, Dec 21, 2012 at 5:45 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> The PL/Python build on OS X is currently hardcoded to use the system
> Python install. If you try to override this when running configure, you
> get a mysterious mix-and-match build. If you want to build against your
> own Python build, or MacPorts or Homebrew, you can't.
>
> This is straightforward to fix. In configure, besides checking Python
> include and library paths, we can also check whether it's a framework
> build and the right parameters for that. The attached patch does that
> and does the job for me. Please test it.
>
> One constraint, which is explained in the comment in
> src/pl/plpython/Makefile is that in Python <2.5, there is no official
> way to detect either framework builds or shared libpython builds, so we
> can't support those versions on OS X, at least without more hardcoding
> of things. I'd rather phase some of that out, but if someone needs to
> continue to use Python 2.4 or earlier on OS X, let me know. (Or more
> proper fix would be to split DLSUFFIX into two variables, but that seems
> more work than it's worth right now.)
This patch seems to have broken the build for our installers for 9.3.
Because we need a consistent build of the PL interpretors on all the
platforms we support, we use the ActiveState distributions of Perl,
Python and TCL (we can't rely on vendor supplied packages, because
their versions vary between different Linux distros and different OS X
versions). However, ActivePython doesn't include a shared library,
which this change seems to require.
Can that requirement be reverted?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
