Re: [HACKERS] is allow_nonpic_in_shlib still useful?
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. -- 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] is allow_nonpic_in_shlib still useful?
Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
