Re: Debian Sid broke Perl

Noah Misch <noah(at)leadboat(dot)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