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.