Commit Graph

37 Commits

Author SHA1 Message Date
Tom Lane
4e5ce3c1ae Reject too-old Python versions a bit sooner.
Commit 04aad4018 added this check after the search for a Python shared
library, which seems to me to be a pretty unfriendly ordering.  The
search might fail for what are basically version-related reasons, and
in such a case it'd be better to say "your Python is too old" than
"could not find shared library for Python".
2017-02-21 11:28:23 -05:00
Peter Eisentraut
04aad40186 Drop support for Python 2.3
There is no specific reason for this right now, but keeping support for
old Python versions around indefinitely increases the maintenance
burden.  The oldest supported Python version is now Python 2.4, which is
still shipped in RHEL/CentOS 5 by default.

In configure, add a check for the required Python version and give a
friendly error message for an old version, instead of relying on an
obscure build error later on.
2017-02-21 09:49:22 -05:00
Tom Lane
17a3a1eb0e Fix python shlib probe for Cygwin.
On buildfarm member cockatiel, that library is in /usr/bin.
(Possibly we should look at $PATH on this platform?)
Per off-list report from Andrew Dunstan.
2016-10-07 11:27:34 -04:00
Tom Lane
11c0e743b6 Try to fix python shlib probe for MinGW.
Per discussion with Andrew Dunstan, it seems there are three peculiarities
of the Python installation on MinGW (or at least, of the instance on
buildfarm member frogmouth).  First, the library name doesn't contain
"2.7" but just "27".  It looks like we can deal with that by consulting
get_config_vars('VERSION') to see whether a dot should be used or not.
Second, the library might be in c:/Windows/System32, analogously to it
possibly being in /usr/lib on Unix-oid platforms.  Third, it's apparently
not standard to use the prefix "lib" on the file name.  This patch will
accept files with or without "lib", but the first part of that may well
be dead code.
2016-10-05 22:47:23 -04:00
Tom Lane
ddd4f82cb6 In python shlib probe, cater for OpenBSD, which omits the .so symlink.
Most Unix-oid platforms provide a symlink "libfoo.so" -> "libfoo.so.n.n"
to allow the linker to resolve a reference "-lfoo" to a version-numbered
shared library.  OpenBSD has apparently hacked ld(1) to do this internally,
because there are no such symlinks to be found in their library
directories.  Tweak the new code in PGAC_CHECK_PYTHON_EMBED_SETUP to cope.
Per buildfarm member curculio.
2016-10-05 11:44:57 -04:00
Tom Lane
fc76259f5b Huh, we do need to look in $python_configdir for the Python shlib.
Debian does it that way, for no doubt what seems to them a good reason.
Thanks to Aidan Van Dyk for confirmation.
2016-10-04 16:38:45 -04:00
Tom Lane
46ddbbb117 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-04 15:23:07 -04:00
Tom Lane
86832eb891 Remove configure check prohibiting threaded libpython on OpenBSD.
According to recent tests, this case now works fine, so there's no reason
to reject it anymore.  (Even if there are still some OpenBSD platforms
in the wild where it doesn't work, removing the check won't break any case
that worked before.)

We can actually remove the entire test that discovers whether libpython
is threaded, since without the OpenBSD case there's no need to know that
at all.

Per report from Davin Potts.  Back-patch to all active branches.
2015-05-26 22:14:59 -04:00
Andrew Dunstan
f707b53449 fix escaping of brackets for m4 broken in b6b2149e48 2015-05-03 09:37:15 -04:00
Andrew Dunstan
b6b2149e48 Fix python_includespec on Windows at configure time
By converting to using forward slashes at configure time we avoid
having to repeat the logic anywhere that this is needed, such as
in transforms modules for plpython.
2015-05-03 08:17:04 -04:00
Peter Eisentraut
d664a10f96 Move interpreter shared library detection to configure
For building PL/Perl, PL/Python, and PL/Tcl, we need a shared library of
libperl, libpython, and libtcl, respectively.  Previously, this was
checked in the makefiles, skipping the PL build with a warning if no
shared library was available.  Now this is checked in configure, with an
error if no shared library is available.

The previous situation arose because in the olden days, the configure
options --with-perl, --with-python, and --with-tcl controlled whether
frontend interfaces for those languages would be built.  The procedural
languages were added later, and shared libraries were often not
available in the beginning.  So it was decided skip the builds of the
procedural languages in those cases.  The frontend interfaces have since
been removed from the tree, and shared libraries are now available most
of the time, so that setup makes much less sense now.

Also, the new setup allows contrib modules and pgxs users to rely on the
respective PLs being available based on configure flags.
2015-05-01 21:38:21 -04:00
Tom Lane
20561acf93 On OS X, link libpython normally, ignoring the "framework" framework.
As of Xcode 5.0, Apple isn't including the Python framework as part of the
SDK-level files, which means that linking to it might fail depending on
whether Xcode thinks you've selected a specific SDK version.  According to
their Tech Note 2328, they've basically deprecated the framework method of
linking to libpython and are telling people to link to the shared library
normally.  (I'm pretty sure this is in direct contradiction to the advice
they were giving a few years ago, but whatever.)  Testing says that this
approach works fine at least as far back as OS X 10.4.11, so let's just
rip out the framework special case entirely.  We do still need a special
case to decide that OS X provides a shared library at all, unfortunately
(I wonder why the distutils check doesn't work ...).  But this is still
less of a special case than before, so it's fine.

Back-patch to all supported branches, since we'll doubtless be hearing
about this more as more people update to recent Xcode.
2014-05-30 18:19:06 -04:00
Tom Lane
5aec9ccafe Fix plpython build on older versions of OS X.
Pre-Lion versions of Apple's linker don't allow space between -F and its
argument.  (Snow Leopard is nice enough to tell you that in so many words,
but older versions just fail with very obscure link errors, as seen on
buildfarm member locust for instance.)  Oversight in commit
fc8745070a.
2013-01-06 15:49:53 -05:00
Peter Eisentraut
fc8745070a PL/Python: Make build on OS X more flexible
The PL/Python build on OS X was previously hardcoded to use the system
installation of Python, ignoring whatever was specified to configure.
Except that it would use the header files from configure, which could
lead to mismatches.  It was not possible to build against a custom
Python installation.

Now, we check in configure how the specified Python installation was
built and use that, supporting framework and non-framework builds.
2013-01-05 08:56:14 -05:00
Peter Eisentraut
9cffb187d8 Also check for Python platform-specific include directory
Python can be built to have two separate include directories: one for
platform-independent files and one for platform-specific files.  So
far, this has apparently never mattered for a PL/Python build.  But
with the new multi-arch Python packages in Debian and Ubuntu, this is
becoming the standard configuration on these platforms, so we must
check these directories separately to be able to build there.

Also add a bit of reporting in configure to be able to see better what
is going on with this.
2012-08-29 23:05:35 -04:00
Tom Lane
c0efc2c2ab Don't reject threaded Python on FreeBSD.
According to Chris Rees, this has worked for awhile, and the current
FreeBSD port is removing the test anyway.
2012-02-20 16:21:28 -05:00
Peter Eisentraut
80ac853f05 python.m4: Remove useless "import string" calls
They have been unneeded since the use of the string module has been
removed in a65ed83f8a.
2011-11-29 06:50:11 +02:00
Peter Eisentraut
f8c2029ef0 Improve detection of Python 3.2 installations
Because of ABI tagging, the library version number might no longer be
exactly the Python version number, so do extra lookups.  This affects
installations without a shared library, such as ActiveState's
installer.

Also update the way to detect the location of the 'config' directory,
which can also be versioned.

Ashesh Vashi
2011-08-18 14:43:16 +03:00
Magnus Hagander
9f2e211386 Remove cvs keywords from all files. 2010-09-20 22:08:53 +02:00
Peter Eisentraut
7e8a60b7c5 Don't link PL/Python against LOCALMODLIBS
This variable is apparently only for Python internally.  In newer releases
of Python this variable pulls in more and more libraries that users are
less likely to have, leading to potential build failures.
2010-03-17 22:02:44 +00:00
Peter Eisentraut
dd4cd55c15 Python 3 support in PL/Python
Behaves more or less unchanged compared to Python 2, but the new language
variant is called plpython3u.  Documentation describing the naming scheme
is included.
2009-12-15 22:59:55 +00:00
Peter Eisentraut
de7ee9e2e9 In the configure check for the Python distutils module, use a less obscure
shell construct to hide away the stderr output.  Python 3.1 actually core
dumps on the current invocation (http://bugs.python.org/issue7111), but the
new version also has the more general advantage of saving the error message
in config.log for analysis.
2009-10-14 21:59:15 +00:00
Peter Eisentraut
a65ed83f8a Allow configure to deal with Python 3.0. Changes were:
print foo --> print(foo)
string.join(...) --> ' '.join(...)

These changes are backward compatible.

The actual plpython module appears to need significant updates to support
Python 3.0, though.  This change just relieves interested developers from
having to deal with Autoconf.
2009-01-04 00:54:15 +00:00
Peter Eisentraut
6ab23dabf5 Punt when trying to build with threaded Python on FreeBSD.
Also cut back on excessive use of *** to decorate configure error messages.
If it's an error message, you are sure to see it without any decoration.
2006-10-16 17:24:54 +00:00
Bruce Momjian
4784794279 Enable threaded python builds on freebsd5, per report from Jim C. Nasby 2005-10-13 20:40:04 +00:00
Bruce Momjian
d3a0c8dce9 Prevent threaded python build on BSD's, where it fails.
Marko Kreen
2005-09-26 16:48:28 +00:00
Tom Lane
669ca7af83 Another try at making plpython autoconfiguration work correctly. Use a
-L spec rather than assuming libpython is in the standard search path
(this returns to the way 7.4 did it).  But check the distutils output
to see if it looks like Python has built a shared library, and if so
link with that instead of the probably-not-shared library found in
configdir.
2004-10-11 19:32:19 +00:00
Tom Lane
86a39d5a19 Un-break plpython build for non-Windows platforms. 2004-10-10 19:07:55 +00:00
Bruce Momjian
5431393274 Allow plpython to build on Win32.
Magnus Hagander
2004-10-06 09:20:41 +00:00
Joe Conway
04d15d120c Make discovery of python_configdir architecture independent. Solution
from James William Pye.
2004-09-16 23:30:30 +00:00
PostgreSQL Daemon
969685ad44 $Header: -> $PostgreSQL Changes ... 2003-11-29 19:52:15 +00:00
Peter Eisentraut
f10a9033bf Clean up after pygresql removal: adjust/remove documentation and remove
unneeded configure work.
2003-09-01 23:01:49 +00:00
Peter Eisentraut
e43ecb3d1a Remove leftovers from subproject removals. Fixes for Python and Kerberos
configuration.
2002-09-04 22:54:18 +00:00
Peter Eisentraut
7c1ff35410 Upgrade to Autoconf version 2.53. Replaced many custom macro
calls with new or now-built-in versions.  Make sure that all
calls to AC_DEFINE have a third argument, for possible use of
autoheader in the future.
2002-03-29 17:32:55 +00:00
Peter Eisentraut
8237d89c0f Support fake root install, separate build dir, dependency tracking, our
choice of compiler and flags, uninstall, and peculiar Python installation
layouts for PyGreSql.  Also install into site-packages now, as officially
recommended.  And pgdb.py is also installed now, used to be forgotten.
2001-07-10 16:33:02 +00:00
Peter Eisentraut
bbc3920fe9 PL/Python should build portably now, if you can get over the fact that
there's no shared libpython.  Test suite works as well. Also, add some
documentation.
2001-05-12 17:49:32 +00:00
Peter Eisentraut
6de89c9ab7 Moved the intricacies of the perl interface build into its own makefile
that now functions as a wrapper around the MakeMaker stuff. It might
even behave sensically when we have separate build dirs. Same for plperl,
which of course still doesn't work very well. Made sure that plperl
respects the choice of --libdir.

Added --with-python to automatically build and install the Python interface.
Works similarly to the Perl5 stuff.

Moved the burden of the distclean targets lower down into the source tree.
Eventually, each make file should have its own.

Added automatic remaking of makefiles and configure. Currently only for the
top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around
missing autoconf and aclocal. Start factoring out macros into their own
config/*.m4 files to increase readability and organization.
2000-06-10 18:02:12 +00:00