2000-06-11 02:02:12 +08:00
|
|
|
#
|
|
|
|
# Autoconf macros for configuring the build of Python extension modules
|
|
|
|
#
|
2010-09-21 04:08:53 +08:00
|
|
|
# config/python.m4
|
2000-06-11 02:02:12 +08:00
|
|
|
#
|
|
|
|
|
2001-05-13 01:49:32 +08:00
|
|
|
# PGAC_PATH_PYTHON
|
2000-06-11 02:02:12 +08:00
|
|
|
# ----------------
|
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
|
|
|
# Look for Python and set the output variable 'PYTHON' if found,
|
|
|
|
# fail otherwise.
|
2019-01-11 22:45:15 +08:00
|
|
|
#
|
|
|
|
# As the Python 3 transition happens and PEP 394 isn't updated, we
|
|
|
|
# need to cater to systems that don't have unversioned "python" by
|
|
|
|
# default. Some systems ship with "python3" by default and perhaps
|
|
|
|
# have "python" in an optional package. Some systems only have
|
|
|
|
# "python2" and "python3", in which case it's reasonable to prefer the
|
|
|
|
# newer version.
|
2001-05-13 01:49:32 +08:00
|
|
|
AC_DEFUN([PGAC_PATH_PYTHON],
|
2019-01-11 22:45:15 +08:00
|
|
|
[PGAC_PATH_PROGS(PYTHON, [python python3 python2])
|
2001-05-13 01:49:32 +08:00
|
|
|
if test x"$PYTHON" = x""; then
|
|
|
|
AC_MSG_ERROR([Python not found])
|
|
|
|
fi
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
|
|
# _PGAC_CHECK_PYTHON_DIRS
|
|
|
|
# -----------------------
|
2017-02-22 00:28:23 +08:00
|
|
|
# Determine the name of various directories of a given Python installation,
|
|
|
|
# as well as the Python version.
|
2001-05-13 01:49:32 +08:00
|
|
|
AC_DEFUN([_PGAC_CHECK_PYTHON_DIRS],
|
|
|
|
[AC_REQUIRE([PGAC_PATH_PYTHON])
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
python_fullversion=`${PYTHON} -c "import sys; print(sys.version)" | sed q`
|
|
|
|
AC_MSG_NOTICE([using python $python_fullversion])
|
|
|
|
# python_fullversion is typically n.n.n plus some trailing junk
|
|
|
|
python_majorversion=`echo "$python_fullversion" | sed '[s/^\([0-9]*\).*/\1/]'`
|
|
|
|
python_minorversion=`echo "$python_fullversion" | sed '[s/^[0-9]*\.\([0-9]*\).*/\1/]'`
|
|
|
|
python_version=`echo "$python_fullversion" | sed '[s/^\([0-9]*\.[0-9]*\).*/\1/]'`
|
|
|
|
# Reject unsupported Python versions as soon as practical.
|
|
|
|
if test "$python_majorversion" -lt 3 -a "$python_minorversion" -lt 7; then
|
|
|
|
AC_MSG_ERROR([Python version $python_version is too old (version 2.7 or later is required)])
|
|
|
|
fi
|
|
|
|
|
|
|
|
AC_MSG_CHECKING([for Python sysconfig module])
|
|
|
|
if "${PYTHON}" -c 'import sysconfig' 2>&AS_MESSAGE_LOG_FD
|
2004-09-17 07:30:30 +08:00
|
|
|
then
|
|
|
|
AC_MSG_RESULT(yes)
|
|
|
|
else
|
|
|
|
AC_MSG_RESULT(no)
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
AC_MSG_ERROR([sysconfig module not found])
|
2004-09-17 07:30:30 +08:00
|
|
|
fi
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
|
2004-10-11 03:07:55 +08:00
|
|
|
AC_MSG_CHECKING([Python configuration directory])
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
python_configdir=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LIBPL'))))"`
|
2012-08-30 10:44:59 +08:00
|
|
|
AC_MSG_RESULT([$python_configdir])
|
|
|
|
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
AC_MSG_CHECKING([Python include directory])
|
|
|
|
python_includespec=`${PYTHON} -c "import sysconfig; print('-I' + sysconfig.get_config_var('INCLUDEPY'))"`
|
2015-05-03 20:17:04 +08:00
|
|
|
if test "$PORTNAME" = win32 ; then
|
2015-05-03 21:37:15 +08:00
|
|
|
python_includespec=`echo $python_includespec | sed 's,[[\]],/,g'`
|
2015-05-03 20:17:04 +08:00
|
|
|
fi
|
2012-08-30 10:44:59 +08:00
|
|
|
AC_MSG_RESULT([$python_includespec])
|
2001-05-13 01:49:32 +08:00
|
|
|
|
2009-12-16 06:59:55 +08:00
|
|
|
AC_SUBST(python_majorversion)[]dnl
|
2004-10-11 03:07:55 +08:00
|
|
|
AC_SUBST(python_version)[]dnl
|
2001-07-11 00:33:02 +08:00
|
|
|
AC_SUBST(python_includespec)[]dnl
|
2001-05-13 01:49:32 +08:00
|
|
|
])# _PGAC_CHECK_PYTHON_DIRS
|
2000-06-11 02:02:12 +08:00
|
|
|
|
|
|
|
|
2001-05-13 01:49:32 +08:00
|
|
|
# PGAC_CHECK_PYTHON_EMBED_SETUP
|
|
|
|
# -----------------------------
|
2004-10-12 03:32:19 +08:00
|
|
|
#
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
# Set python_libdir to the path of the directory containing the Python shared
|
|
|
|
# library. Set python_libspec to the -L/-l linker switches needed to link it.
|
|
|
|
# Set python_additional_libs to contain any additional linker switches needed
|
|
|
|
# for subsidiary libraries.
|
|
|
|
#
|
|
|
|
# In modern, well-configured Python installations, LIBDIR gives the correct
|
|
|
|
# directory name and LDLIBRARY is the file name of the shlib. But in older
|
|
|
|
# installations LDLIBRARY is frequently a useless path fragment, and it's also
|
|
|
|
# possible that the shlib is in a standard library directory such as /usr/lib
|
2016-10-05 04:38:45 +08:00
|
|
|
# so that LIBDIR is irrelevant. Also, some packagers put the .so symlink for
|
|
|
|
# the shlib in ${python_configdir} even though Python itself never does.
|
|
|
|
# We must also check that what we found is a shared library not a plain
|
|
|
|
# library, which we do by checking its extension. (We used to rely on
|
|
|
|
# Py_ENABLE_SHARED, but that only tells us that a shlib exists, not that
|
|
|
|
# we found it.)
|
2001-05-13 01:49:32 +08:00
|
|
|
AC_DEFUN([PGAC_CHECK_PYTHON_EMBED_SETUP],
|
|
|
|
[AC_REQUIRE([_PGAC_CHECK_PYTHON_DIRS])
|
|
|
|
AC_MSG_CHECKING([how to link an embedded Python application])
|
|
|
|
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
python_libdir=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LIBDIR'))))"`
|
|
|
|
python_ldlibrary=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LDLIBRARY'))))"`
|
2004-10-12 03:32:19 +08:00
|
|
|
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
# If LDLIBRARY exists and has a shlib extension, use it verbatim.
|
|
|
|
ldlibrary=`echo "${python_ldlibrary}" | sed -e 's/\.so$//' -e 's/\.dll$//' -e 's/\.dylib$//' -e 's/\.sl$//'`
|
|
|
|
if test -e "${python_libdir}/${python_ldlibrary}" -a x"${python_ldlibrary}" != x"${ldlibrary}"
|
2004-10-12 03:32:19 +08:00
|
|
|
then
|
|
|
|
ldlibrary=`echo "${ldlibrary}" | sed "s/^lib//"`
|
2016-10-05 23:44:57 +08:00
|
|
|
found_shlib=1
|
2004-10-12 03:32:19 +08:00
|
|
|
else
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
# Otherwise, guess the base name of the shlib.
|
2016-10-06 10:47:23 +08:00
|
|
|
# LDVERSION was added in Python 3.2, before that use VERSION,
|
|
|
|
# or failing that, $python_version from _PGAC_CHECK_PYTHON_DIRS.
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
python_ldversion=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LDVERSION'))))"`
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
if test x"${python_ldversion}" != x""; then
|
|
|
|
ldlibrary="python${python_ldversion}"
|
|
|
|
else
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
python_version_var=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('VERSION'))))"`
|
2016-10-06 10:47:23 +08:00
|
|
|
if test x"${python_version_var}" != x""; then
|
|
|
|
ldlibrary="python${python_version_var}"
|
|
|
|
else
|
|
|
|
ldlibrary="python${python_version}"
|
|
|
|
fi
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
fi
|
|
|
|
# Search for a likely-looking file.
|
|
|
|
found_shlib=0
|
2016-10-05 04:38:45 +08:00
|
|
|
for d in "${python_libdir}" "${python_configdir}" /usr/lib64 /usr/lib
|
|
|
|
do
|
2016-10-05 23:44:57 +08:00
|
|
|
# We don't know the platform DLSUFFIX here, so check 'em all.
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
for e in .so .dll .dylib .sl; do
|
|
|
|
if test -e "$d/lib${ldlibrary}$e"; then
|
|
|
|
python_libdir="$d"
|
|
|
|
found_shlib=1
|
|
|
|
break 2
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
done
|
2016-10-05 23:44:57 +08:00
|
|
|
# Some platforms (OpenBSD) require us to accept a bare versioned shlib
|
|
|
|
# (".so.n.n") as well. However, check this only after failing to find
|
|
|
|
# ".so" anywhere, because yet other platforms (Debian) put the .so
|
|
|
|
# symlink in a different directory from the underlying versioned shlib.
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
if test "$found_shlib" != 1; then
|
2016-10-05 23:44:57 +08:00
|
|
|
for d in "${python_libdir}" "${python_configdir}" /usr/lib64 /usr/lib
|
|
|
|
do
|
|
|
|
for f in "$d/lib${ldlibrary}.so."* ; do
|
|
|
|
if test -e "$f"; then
|
|
|
|
python_libdir="$d"
|
|
|
|
found_shlib=1
|
|
|
|
break 2
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
done
|
|
|
|
fi
|
2016-10-07 23:27:34 +08:00
|
|
|
# As usual, Windows has its own ideas. Possible default library
|
|
|
|
# locations include c:/Windows/System32 and (for Cygwin) /usr/bin,
|
|
|
|
# and the "lib" prefix might not be there.
|
|
|
|
if test "$found_shlib" != 1 -a \( "$PORTNAME" = win32 -o "$PORTNAME" = cygwin \); then
|
|
|
|
for d in "${python_libdir}" "${python_configdir}" c:/Windows/System32 /usr/bin
|
2016-10-06 10:47:23 +08:00
|
|
|
do
|
|
|
|
for f in "$d/lib${ldlibrary}.dll" "$d/${ldlibrary}.dll" ; do
|
|
|
|
if test -e "$f"; then
|
|
|
|
python_libdir="$d"
|
|
|
|
found_shlib=1
|
|
|
|
break 2
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
done
|
|
|
|
fi
|
2016-10-05 23:44:57 +08:00
|
|
|
fi
|
|
|
|
if test "$found_shlib" != 1; then
|
|
|
|
AC_MSG_ERROR([could not find shared library for Python
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
You might have to rebuild your Python installation. Refer to the
|
|
|
|
documentation for details. Use --without-python to disable building
|
|
|
|
PL/Python.])
|
2004-10-12 03:32:19 +08:00
|
|
|
fi
|
Improve (I hope) our autolocation of the Python shared library.
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>
2016-10-05 03:23:02 +08:00
|
|
|
python_libspec="-L${python_libdir} -l${ldlibrary}"
|
2004-10-12 03:32:19 +08:00
|
|
|
|
Replace use of deprecated Python module distutils.sysconfig, take 2.
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
2022-02-02 08:03:41 +08:00
|
|
|
python_additional_libs=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LIBS','LIBC','LIBM','BASEMODLIBS'))))"`
|
2001-05-13 01:49:32 +08:00
|
|
|
|
2004-10-12 03:32:19 +08:00
|
|
|
AC_MSG_RESULT([${python_libspec} ${python_additional_libs}])
|
2001-05-13 01:49:32 +08:00
|
|
|
|
2004-10-12 03:32:19 +08:00
|
|
|
AC_SUBST(python_libdir)[]dnl
|
2001-05-13 01:49:32 +08:00
|
|
|
AC_SUBST(python_libspec)[]dnl
|
2004-10-12 03:32:19 +08:00
|
|
|
AC_SUBST(python_additional_libs)[]dnl
|
2005-09-27 00:48:28 +08:00
|
|
|
|
2001-05-13 01:49:32 +08:00
|
|
|
])# PGAC_CHECK_PYTHON_EMBED_SETUP
|