Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2
Date: 2011-08-17 17:20:32
Message-ID: 27476.1313601632@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On ons, 2011-08-17 at 18:28 +0530, Ashesh Vashi wrote:
>> When I tried to figure out the exact reason for the failure, I found that:
>> 1. 'python_configdir' variable is hardcoded, instead it should use the
>> configuration 'LIBPL'.

> That looks reasonable. My Debian installation works around this by a
> symlink, but that's perhaps a hack they put in for this reason.

FWIW, all three python installations I have handy (2.7 on Fedora 14, 2.7
on OS X Lion, 2.5 on HPUX) produce the same result from either of

python -c "from distutils.sysconfig import get_python_lib as f; import os; print(os.path.join(f(plat_specific=1,standard_lib=1),'config'))"
python -c "import distutils.sysconfig,string; print(' '.join(filter(None,distutils.sysconfig.get_config_vars('LIBPL'))))"

It's not immediately apparent to me why we should think that
get_python_lib is less trustworthy than LIBPL; but if someone
can make that case, I don't have any objection to this part of
the patch.

>> 2. 'plpython' is trying get linked using '-lpython${*python_version*}', but
>> it should be '-lpython${*python_ldversion*}'.

> That, on the other hand, will be a problem.
> get_config_vars('LDVERSION') isn't defined before Python 3.2, so this
> will break all previous versions.

Yes. In particular, this appears to be doing the wrong thing on my Lion
installation: it changes
python_libspec = -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -lpython2.7
to just
python_libspec = -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -lpython
and there is no libpython.dylib in that directory. The build
accidentally fails to fail because there is a libpython.dylib
in /usr/lib and it happens to be symlinked to the right version of
python, but I hardly think we want to trust that.

I'm also wondering why a patch that's supposed to enable building
against python 3.2 should need to touch the "old way" code path.
If 3.2 isn't using the "new way", what exactly does?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-08-17 17:25:16 Re: A note about hash-based catcache invalidations
Previous Message Charles.McDevitt 2011-08-17 17:12:45 Re: non-ipv6 vs hostnames