Re: 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.