Thread: is allow_nonpic_in_shlib still useful?

In the plperl and plpython makefiles we look for a shared library of
libperl or libpython, and if it's not found, we check for
allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
Apparently, and IIRC, this was set up in a time when those shared
libraries were not available through standard builds, but I think that
hasn't been the case for quite a while.

The only platforms where we set allow_nonpick_in_shlib is linux and
freebsd/i386 (presumably an obsolescent combination).  Are there any
Linux builds that don't supply the required shared libraries?

I suspend this hack isn't useful anymore and ought to be removed.

On Sat, Dec 15, 2012 at 01:23:38AM -0500, Peter Eisentraut wrote:
> In the plperl and plpython makefiles we look for a shared library of
> libperl or libpython, and if it's not found, we check for
> allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
> Apparently, and IIRC, this was set up in a time when those shared
> libraries were not available through standard builds, but I think that
> hasn't been the case for quite a while.
> 
> The only platforms where we set allow_nonpick_in_shlib is linux and
> freebsd/i386 (presumably an obsolescent combination).  Are there any
> Linux builds that don't supply the required shared libraries?

I can't recall such a system.  On x86_64, GNU ld would reject the resulting
text relocations anyway.

> I suspend this hack isn't useful anymore and ought to be removed.

Agreed.  On !allow_nonpic_in_shlib systems, the effect appears to be that we
quietly skip the plperl build, despite --with-perl, when the Perl build lacks
a shlib.  This seems unhelpful; I think --with-perl should result in either an
error or a built plperl.  Likewise for plpython.  The coincidentally-better
build behavior under allow_nonpic_in_shlib should become unconditional.

Peter Eisentraut <peter_e@gmx.net> writes:
> In the plperl and plpython makefiles we look for a shared library of
> libperl or libpython, and if it's not found, we check for
> allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
> Apparently, and IIRC, this was set up in a time when those shared
> libraries were not available through standard builds, but I think that
> hasn't been the case for quite a while.

> The only platforms where we set allow_nonpick_in_shlib is linux and
> freebsd/i386 (presumably an obsolescent combination).  Are there any
> Linux builds that don't supply the required shared libraries?

Doubt it.  I'm pretty sure that every Linux distro would strongly
discourage linking static libraries as large as perl or python into
another package anyway, because of the difficulty of applying security
updates for said libraries if this has been done.  In Red Hat's distros,
static libraries aren't shipped *at all* without a damn good
package-specific reason --- and neither the perl nor python packages
provide such a library AFAICT.

FreeBSD might be a different story though.
        regards, tom lane