Noah Misch <noah@leadboat.com> writes:
> On Sat, Jun 06, 2020 at 07:11:51PM -0400, Tom Lane wrote:
>> I wonder whether we could just drop the configure-time
>> test for useshrplib.
> Losing that would not hurt much. This solution relies on all other Perl
> configure tests getting the same answer from /usr/bin/perl that they would get
> from /usr/bin/perl*gnu.
Aye, there's the rub.
> thorntail currently does behave that way:
Does not, you mean? This part looks pretty fatal to the idea:
> @@ -919,7 +920,7 @@
> lib_ext='.a'
> libc='libc-2.31.so'
> libdb_needs_pthread='N'
> -libperl='libperl.a'
> +libperl='libperl.so.5.30'
> libpth='/usr/local/lib /usr/include/sparc64-linux-gnu /usr/lib /lib/sparc64-linux-gnu /lib/../lib
/usr/lib/sparc64-linux-gnu/usr/lib/../lib /lib'
> libs='-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt'
> libsdirs=' /usr/lib/sparc64-linux-gnu'
We can't accept linking plperl to the static libperl.a --- even if it
manages to work, which it won't on some hardware, that would result in
libperl becoming embedded in plperl.so. That breaks every rule of good
distribution management.
I fear we shall have to push back against this as a breaking change.
We can't realistically be expected to look for some non-default version
of perl to get our build settings from.
However ... if I'm reading perl.m4 correctly, what actually matters
here is what we get from
$PERL -MExtUtils::Embed -e ldopts
Could you double-check what that produces in each case?
regards, tom lane