Re: is allow_nonpic_in_shlib still useful? - Mailing list pgsql-hackers

From Noah Misch
Subject Re: is allow_nonpic_in_shlib still useful?
Date
Msg-id 20121215132211.GB10608@tornado.leadboat.com
Whole thread Raw
In response to is allow_nonpic_in_shlib still useful?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: small pg_basebackup display bug
Next
From: "Erik Rijkers"
Date:
Subject: Re: small pg_basebackup display bug