Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 18:36:18
Message-ID: 1313606178.19987.14.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote:
> 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.

The issue, at least for me, is that the file isn't necessarily called
'config' anymore. I have

/usr/lib/python3.2/config-3.2mu

because of some shared object ABI tagging system they introduced.
(/usr/lib/python3.2/config is a symlink to that, as a transition
measure, I guess.)

LIBPL exists at least as far back as Python 2.2, so its use should be
safe.

> >> 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.

Yes, because get_config_vars('LDVERSION') doesn't exist in that version.
In theory, it would return '2.7', so everything would fit back together,
but LDVERSION doesn't exist before 3.2.

> 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?

Analogously to the point above, the result on my system should be

-L something -lpython3.2mu

And that's what I get.

The claim is that on the ActiveState installation, this doesn't work
out, but we need to see some details here, I guess.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-08-17 19:55:03 Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2
Previous Message Peter Eisentraut 2011-08-17 18:28:33 Re: non-ipv6 vs hostnames