You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
postgres/config/python.m4

183 lines
6.9 KiB

#
# Autoconf macros for configuring the build of Python extension modules
#
# config/python.m4
#
# PGAC_PATH_PYTHON
# ----------------
# Look for Python and set the output variable 'PYTHON' if found,
# fail otherwise.
#
# Since we are supporting only Python 3.x, prefer python3 to plain python. If
# the latter exists at all, it very possibly points to python2.
# 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.
AC_DEFUN([PGAC_PATH_PYTHON],
[PGAC_PATH_PROGS(PYTHON, [python3 python])
AC_ARG_VAR(PYTHON, [Python program])dnl
if test x"$PYTHON" = x""; then
AC_MSG_ERROR([Python not found])
fi
])
# _PGAC_CHECK_PYTHON_DIRS
# -----------------------
# Determine the name of various directories of a given Python installation,
# as well as the Python version.
AC_DEFUN([_PGAC_CHECK_PYTHON_DIRS],
[AC_REQUIRE([PGAC_PATH_PYTHON])
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; then
AC_MSG_ERROR([Python version $python_version is too old (version 3 or later is required)])
fi
AC_MSG_CHECKING([for Python sysconfig module])
if "${PYTHON}" -c 'import sysconfig' 2>&AS_MESSAGE_LOG_FD
then
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
AC_MSG_ERROR([sysconfig module not found])
fi
AC_MSG_CHECKING([Python configuration directory])
python_configdir=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LIBPL'))))"`
AC_MSG_RESULT([$python_configdir])
AC_MSG_CHECKING([Python include directory])
python_includespec=`${PYTHON} -c "import sysconfig; print('-I' + sysconfig.get_config_var('INCLUDEPY'))"`
if test "$PORTNAME" = win32 ; then
python_includespec=`echo $python_includespec | sed 's,[[\]],/,g'`
fi
AC_MSG_RESULT([$python_includespec])
AC_SUBST(python_majorversion)[]dnl
AC_SUBST(python_version)[]dnl
AC_SUBST(python_includespec)[]dnl
])# _PGAC_CHECK_PYTHON_DIRS
# PGAC_CHECK_PYTHON_EMBED_SETUP
# -----------------------------
#
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>
10 years ago
# 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
# 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.)
AC_DEFUN([PGAC_CHECK_PYTHON_EMBED_SETUP],
[AC_REQUIRE([_PGAC_CHECK_PYTHON_DIRS])
AC_MSG_CHECKING([how to link an embedded Python application])
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'))))"`
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>
10 years ago
# 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$//'`
Restore AIX support. The concerns that led us to remove AIX support in commit 0b16bb877 have now been alleviated: 1. IBM has stepped forward to provide support, including buildfarm animal(s). 2. AIX 7.2 and later seem to be fine with large pg_attribute_aligned requirements. Since 7.1 is now EOL anyway, we can just cease to support it. 3. Tossing xlc support overboard seems okay as well. It's a bit sad to drop one of the few remaining non-gcc-alike compilers, but working around xlc's bugs and idiosyncrasies doesn't seem justified by the theoretical portability benefits. 4. Likewise, we can stop supporting 32-bit AIX builds. This is not so much about whether we could build such executables as that they're too much of a pain to manage in the field, due to limited address space available for dynamic library loading. 5. We hit on a way to manage catalog column alignment that doesn't require continuing developer effort (see commit ecae09725). Hence, this commit reverts 0b16bb877 and some follow-on commits such as e6bb491bf, except for not putting back XLC support nor the changes related to catalog column alignment. Some other notable changes from the way things were in v16: Prefer unnamed POSIX semaphores on AIX, rather than the default choice of SysV semaphores. Include /opt/freeware/lib in -Wl,-blibpath, even when it is not mentioned anywhere in LDFLAGS. Remove platform-specific adjustment of MEMSET_LOOP_LIMIT; maybe that's still the right thing, but it really ought to be re-tested. Silence compiler warnings related to getpeereid(), wcstombs_l(), and PAM conversation procs. Accept "libpythonXXX.a" as an okay name for the Python shared library (but only on AIX!). Author: Aditya Kamath <Aditya.Kamath1@ibm.com> Author: Srirama Kucherlapati <sriram.rk@in.ibm.com> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CY5PR11MB63928CC05906F27FB10D74D0FD322@CY5PR11MB6392.namprd11.prod.outlook.com
5 days ago
if test "$PORTNAME" = "aix"; then
# On AIX, '.a' should also be believed to be a shlib.
ldlibrary=`echo "${ldlibrary}" | sed -e 's/\.a$//'`
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>
10 years ago
if test -e "${python_libdir}/${python_ldlibrary}" -a x"${python_ldlibrary}" != x"${ldlibrary}"
then
ldlibrary=`echo "${ldlibrary}" | sed "s/^lib//"`
found_shlib=1
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>
10 years ago
# Otherwise, guess the base name of the shlib.
# LDVERSION was added in Python 3.2, before that use VERSION,
# or failing that, $python_version from _PGAC_CHECK_PYTHON_DIRS.
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>
10 years ago
if test x"${python_ldversion}" != x""; then
ldlibrary="python${python_ldversion}"
else
python_version_var=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('VERSION'))))"`
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>
10 years ago
fi
# Search for a likely-looking file.
found_shlib=0
for d in "${python_libdir}" "${python_configdir}" /usr/lib64 /usr/lib
do
if test -e "$d/lib${ldlibrary}${DLSUFFIX}"; then
python_libdir="$d"
found_shlib=1
break 2
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>
10 years ago
done
# 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>
10 years ago
if test "$found_shlib" != 1; then
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
# 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
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
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>
10 years ago
You might have to rebuild your Python installation. Refer to the
documentation for details. Use --without-python to disable building
PL/Python.])
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>
10 years ago
python_libspec="-L${python_libdir} -l${ldlibrary}"
python_additional_libs=`${PYTHON} -c "import sysconfig; print(' '.join(filter(None,sysconfig.get_config_vars('LIBS','LIBC','LIBM','BASEMODLIBS'))))"`
AC_MSG_RESULT([${python_libspec} ${python_additional_libs}])
AC_SUBST(python_libdir)[]dnl
AC_SUBST(python_libspec)[]dnl
AC_SUBST(python_additional_libs)[]dnl
])# PGAC_CHECK_PYTHON_EMBED_SETUP