Re: [HACKERS] shared_libperl, shared_libpython
On 4/28/15 11:48 PM, Tom Lane wrote:
My preference would be to rip all that out and let the compiler or
linker decide when it doesn't want to link something.
Works for me, assuming that we get an understandable failure message and
not, say, a plperl.so that mysteriously doesn't work.
Well, I can't really guarantee that, and I also recall that in some
cases a shared/non-shared mismatch will work but be slow or something
like that.
So I went for the configure detection. For Perl, this is
straightforward. For Python and Tcl, it gets tricky because they look
at the actual file in some cases, which requires knowing DLSUFFIX, which
is not available in configure. (And it's a lie anyway, because on OS X
it does not distinguish between .so and .dylib in a principled way.)
For Tcl, this is only necessary for version before Tcl 8.0 (according to
code comments), which I think we can safely drop. For Python, it's
still necessary, so I hardcoded a few choices in an ugly way.
I think overall this patch is still an improvement in several ways.
Worst case, we could turn some of these configure errors into warnings.
diff --git a/config/python.m4 b/config/python.m4
index 7012c53..c8f784e 100644
--- a/config/python.m4
+++ b/config/python.m4
@@ -93,7 +93,6 @@ AC_MSG_RESULT([${python_libspec} ${python_additional_libs}])
AC_SUBST(python_libdir)[]dnl
AC_SUBST(python_libspec)[]dnl
AC_SUBST(python_additional_libs)[]dnl
-AC_SUBST(python_enable_shared)[]dnl
# threaded python is not supported on OpenBSD
AC_MSG_CHECKING(whether Python is compiled with thread support)
diff --git a/configure b/configure
index 7c0bd0c..cddbbef 100755
--- a/configure
+++ b/configure
@@ -641,7 +641,6 @@ TCL_SHLIB_LD_LIBS
TCL_SHARED_BUILD
TCL_LIB_SPEC
TCL_LIBS
-TCL_LIB_FILE
TCL_INCLUDE_SPEC
TCL_CONFIG_SH
TCLSH
@@ -662,7 +661,6 @@ HAVE_IPV6
LIBOBJS
UUID_LIBS
ZIC
-python_enable_shared
python_additional_libs
python_libspec
python_libdir
@@ -7384,6 +7382,12 @@ perl_useshrplib=`$PERL -MConfig -e 'print $Config{useshrplib}'`
test $PORTNAME = win32 perl_useshrplib=`echo $perl_useshrplib | sed 's,,/,g'`
{ $as_echo $as_me:${as_lineno-$LINENO}: result: $perl_useshrplib 5
$as_echo $perl_useshrplib 6; }
+ if test $perl_useshrplib != yes test $perl_useshrplib != true; then
+as_fn_error $? cannot build PL/Perl because libperl is not a shared library
+You might have to rebuild your Perl installation. Refer to the
+documentation for details. Use --without-perl to disable building
+PL/Perl. $LINENO 5
+ fi
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for flags to link embedded Perl 5
$as_echo_n checking for flags to link embedded Perl... 6; }
@@ -7537,6 +7541,33 @@ $as_echo no 6; }
fi
+
+ # We need libpython as a shared library. In Python =2.5, we asks
+ # Python directly. But because this has been broken in Debian for a
+ # long time (http://bugs.debian.org/695979), and to support older
+ # Python versions, we see if there is a file that is named like a
+ # shared library as a fallback.
+
+ if test $python_enable_shared != 11; then
+# OS X does supply a .dylib even though Py_ENABLE_SHARED does not get set
+if test $PORTNAME = darwinX; then
+ python_enable_shared=1
+else
+ for dlsuffix in .so .dll .sl; do
+if ls $python_libdir/libpython*${dlsuffix}* /dev/null 21; then
+ python_enable_shared=1
+ break
+fi
+ done
+fi
+ fi
+
+ if test $python_enable_shared != 1; then
+as_fn_error $? cannot build PL/Python because libpython is not a shared library
+You might have to rebuild your Python installation. Refer to the
+documentation for details. Use --without-python to disable building
+PL/Python. $LINENO 5
+ fi
fi
if test $cross_compiling = yes test -z $with_system_tzdata; then
@@ -14736,12 +14767,15 @@ fi
. $TCL_CONFIG_SH
eval TCL_INCLUDE_SPEC=\$TCL_INCLUDE_SPEC\
-eval TCL_LIB_FILE=\$TCL_LIB_FILE\
eval TCL_LIBS=\$TCL_LIBS\
eval TCL_LIB_SPEC=\$TCL_LIB_SPEC\
eval TCL_SHARED_BUILD=\$TCL_SHARED_BUILD\
-# now that we have TCL_INCLUDE_SPEC, we can check for tcl.h
+if test $TCL_SHARED_BUILD != 1; then
+ as_fn_error $? cannot build PL/Tcl because Tcl is not a shared library
+Use --without-tcl to disable building PL/Tcl. $LINENO 5
+fi
+# now that we have TCL_INCLUDE_SPEC, we can check for tcl.h
ac_save_CPPFLAGS=$CPPFLAGS
CPPFLAGS=$TCL_INCLUDE_SPEC $CPPFLAGS
ac_fn_c_check_header_mongrel $LINENO tcl.h ac_cv_header_tcl_h $ac_includes_default
diff --git a/configure.in b/configure.in
index 1cd9e1e..a9e2257 100644
--- a/configure.in
+++ b/configure.in
@@ -889,12 +889,45 @@ if test $with_perl = yes; then
AC_MSG_ERROR([Perl not found])
fi
PGAC_CHECK_PERL_CONFIGS([archlibexp,privlibexp,useshrplib])
+ if test $perl_useshrplib != yes test $perl_useshrplib != true; then
+AC_MSG_ERROR([cannot build PL/Perl because libperl is not a shared library
+You might have to rebuild your Perl
Re: [HACKERS] shared_libperl, shared_libpython
On Wed, Apr 29, 2015 at 12:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: On 4/28/15 12:05 AM, Tom Lane wrote: Yeah. Even more specifically, olinguito does have --with-python in its configure flags, but then the plpython Makefile skips the build because libpython isn't available as a shared library. But the contrib test is (I assume, haven't looked) conditional only on the configure flag. I'm not real sure now why we felt that was a good approach. The general project policy is that if you ask for a feature in the configure flags, we'll build it or die trying; how come this specific Python issue gets special treatment contrary to that policy? The reason for the current setup is actually that when plperl and later plpython was added, we still had Perl and Python client modules in our tree (Pg.pm and pygresql), and configure --with-perl and --with-python were meant to activate their build primarily. Also, in those days, having a shared libperl or libpython was rare. But we didn't want to fail the frontend interface builds because of that. So we arrived at the current workaround. Ah. I'm glad you remember, because I didn't. Interesting, those are pieces of history: commit: f10a9033bf308f9dde0aa77caad6503e233489d1 author: Peter Eisentraut pete...@gmx.net date: Mon, 1 Sep 2003 23:01:49 + Clean up after pygresql removal: adjust/remove documentation and remove unneeded configure work. commit: 9a0b4d7f847469544798133391e221481548e1b9 author: Marc G. Fournier scra...@hub.org date: Fri, 30 Aug 2002 13:06:22 + perl5 interface moved to gborg My preference would be to rip all that out and let the compiler or linker decide when it doesn't want to link something. Works for me, assuming that we get an understandable failure message and not, say, a plperl.so that mysteriously doesn't work. +1. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] shared_libperl, shared_libpython
On 04/28/2015 04:31 PM, Peter Eisentraut wrote: On 4/28/15 12:05 AM, Tom Lane wrote: Yeah. Even more specifically, olinguito does have --with-python in its configure flags, but then the plpython Makefile skips the build because libpython isn't available as a shared library. But the contrib test is (I assume, haven't looked) conditional only on the configure flag. I'm not real sure now why we felt that was a good approach. The general project policy is that if you ask for a feature in the configure flags, we'll build it or die trying; how come this specific Python issue gets special treatment contrary to that policy? So I'd vote for changing that to put the shared-library test in configure, or at least make it a build failure later on, not silently don't build what was asked for. That would mean olinguito's configure flags would have to be adjusted. Plan B would require propagating the shared-libpython test into the contrib makefiles, which seems pretty unpalatable even if you're willing to defend the status quo otherwise. I had tried plan B prime, moving the shared_libpython etc. detection into Makefile.global. But that doesn't work because contrib/pgxs makefiles require setting all variables *before* including the global makefiles. So you can't decide whether you want to build something before you have told it everything you want to build. The reason for the current setup is actually that when plperl and later plpython was added, we still had Perl and Python client modules in our tree (Pg.pm and pygresql), and configure --with-perl and --with-python were meant to activate their build primarily. Also, in those days, having a shared libperl or libpython was rare. But we didn't want to fail the frontend interface builds because of that. So we arrived at the current workaround. My preference would be to rip all that out and let the compiler or linker decide when it doesn't want to link something. The alternative would be creating a configure check that mirrors the current logic. Arguably, however, the current logic is quite unworthy of a configure check, because it's just a collection of on-this-platform-do-that, instead of a real test. Then again, a real test would require building and loading a shared library in configure, and we are not set up for that. Preferences? In general I prefer things not being available to be tested at configure time. After all, we check for libxml2, for example. Certainly silent failure is a bad thing. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] shared_libperl, shared_libpython
Peter Eisentraut pete...@gmx.net writes: On 4/28/15 12:05 AM, Tom Lane wrote: Yeah. Even more specifically, olinguito does have --with-python in its configure flags, but then the plpython Makefile skips the build because libpython isn't available as a shared library. But the contrib test is (I assume, haven't looked) conditional only on the configure flag. I'm not real sure now why we felt that was a good approach. The general project policy is that if you ask for a feature in the configure flags, we'll build it or die trying; how come this specific Python issue gets special treatment contrary to that policy? The reason for the current setup is actually that when plperl and later plpython was added, we still had Perl and Python client modules in our tree (Pg.pm and pygresql), and configure --with-perl and --with-python were meant to activate their build primarily. Also, in those days, having a shared libperl or libpython was rare. But we didn't want to fail the frontend interface builds because of that. So we arrived at the current workaround. Ah. I'm glad you remember, because I didn't. My preference would be to rip all that out and let the compiler or linker decide when it doesn't want to link something. Works for me, assuming that we get an understandable failure message and not, say, a plperl.so that mysteriously doesn't work. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] shared_libperl, shared_libpython
On 4/28/15 12:05 AM, Tom Lane wrote: Yeah. Even more specifically, olinguito does have --with-python in its configure flags, but then the plpython Makefile skips the build because libpython isn't available as a shared library. But the contrib test is (I assume, haven't looked) conditional only on the configure flag. I'm not real sure now why we felt that was a good approach. The general project policy is that if you ask for a feature in the configure flags, we'll build it or die trying; how come this specific Python issue gets special treatment contrary to that policy? So I'd vote for changing that to put the shared-library test in configure, or at least make it a build failure later on, not silently don't build what was asked for. That would mean olinguito's configure flags would have to be adjusted. Plan B would require propagating the shared-libpython test into the contrib makefiles, which seems pretty unpalatable even if you're willing to defend the status quo otherwise. I had tried plan B prime, moving the shared_libpython etc. detection into Makefile.global. But that doesn't work because contrib/pgxs makefiles require setting all variables *before* including the global makefiles. So you can't decide whether you want to build something before you have told it everything you want to build. The reason for the current setup is actually that when plperl and later plpython was added, we still had Perl and Python client modules in our tree (Pg.pm and pygresql), and configure --with-perl and --with-python were meant to activate their build primarily. Also, in those days, having a shared libperl or libpython was rare. But we didn't want to fail the frontend interface builds because of that. So we arrived at the current workaround. My preference would be to rip all that out and let the compiler or linker decide when it doesn't want to link something. The alternative would be creating a configure check that mirrors the current logic. Arguably, however, the current logic is quite unworthy of a configure check, because it's just a collection of on-this-platform-do-that, instead of a real test. Then again, a real test would require building and loading a shared library in configure, and we are not set up for that. Preferences? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
