Re: shared_libperl, shared_libpython

Peter Eisentraut <peter_e@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