Improve (I hope) our autolocation of the Python shared library

Enterprise / PostgreSQL - Tom Lane [sss.pgh.pa.us] - 4 October 2016 14:23 UTC

Older versions of Python produce garbage (or at least useless) values of get_config_vars('LDLIBRARY'). Newer versions produce garbage (or at least useless) values of get_config_vars('SO'), which was defeating our configure logic that attempted to identify where the Python shlib really is. The net result, at least with a stock Python 3.5 installation on macOS, was that we were linking against a static library in the mistaken belief that it was a shared library. This managed to work, if you count statically absorbing libpython into plpython.so as working. But it no longer works as of commit d51924be8, because now we get separate static copies of libpython in plpython.so and hstore_plpython.so, and those can't interoperate on the same data. There are some other infelicities like assuming that nobody ever installs a private version of Python on a macOS machine.

Hence, forget about looking in $python_configdir for the Python shlib; as far as I can tell no version of Python has ever put one there, and certainly no currently-supported version does. Also, rather than relying on get_config_vars('SO'), just try all the possibilities for shlib extensions. Also, rather than trusting Py_ENABLE_SHARED, believe we've found a shlib only if it has a recognized extension. Last, explicitly cope with the possibility that the shlib is really in /usr/lib and $python_libdir is a red herring --- this is the actual situation on older macOS, but we were only accidentally working with it.

Discussion: <5300.1475592228@sss.pgh.pa.us>

46ddbbb Improve (I hope) our autolocation of the Python shared library.
config/python.m4 | 57 +++++++++++++++++++++++++++++-------------
configure | 73 ++++++++++++++++++++----------------------------------
configure.in | 34 -------------------------
3 files changed, 67 insertions(+), 97 deletions(-)

Upstream: git.postgresql.org

  • Share