Re: PL/perl should fail on configure, not make

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Subject: Re: PL/perl should fail on configure, not make
Date: 2013-01-10 00:56:57
Message-ID: 10513.1357779417@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 01/09/2013 04:12 PM, Tom Lane wrote:
>> Looks good. If you're happy with that then I can undertake to add a
>> libperl.so probe based on AC_TRY_LINK with the unmodified value of
>> $perl_embed_ldflags.

> Go for it.

Done, we'll soon see how much the buildfarm likes it. (I did test on
Fedora, OS X, and a from-source build on HPUX, though.)

While attempting to test this, I found out that my previous statement
that this failure is impossible on Red Hat platforms actually needs no
qualification. I had supposed that it would be possible to test the
failure path with sufficiently aggressive damage to the local perl
installation, but it's not. Observe:

$ which perl
/usr/bin/perl
$ ldd /usr/bin/perl
linux-vdso.so.1 => (0x00007fffe03ff000)
libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x0000003c0d400000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003831600000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003843600000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000382fe00000)
libm.so.6 => /lib64/libm.so.6 (0x000000382fa00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003c0d800000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003842a00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000382f600000)
libc.so.6 => /lib64/libc.so.6 (0x000000382f200000)
/lib64/ld-linux-x86-64.so.2 (0x000000382ee00000)
libfreebl3.so => /lib64/libfreebl3.so (0x0000003c0e000000)
$ ls -l /usr/lib64/perl5/CORE/libperl*
-rwxr-xr-x. 1 root root 1552816 Nov 26 10:25 /usr/lib64/perl5/CORE/libperl.so

That is, the standard perl executable depends on libperl.so --- not
libperl.so.M.N, which isn't even there. Take the .so away, and you
don't get past configure's initial perl-related checks, because
/usr/bin/perl is broken. This isn't a Red-Hat-ism, either, because my
direct-from-upstream-source build on my old HPUX box is the same way.

I conclude that Debian has positively striven to be randomly different
from the rest of the Perl world, and so my sympathy for their packaging
design is even lower than it was this morning.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-01-10 01:49:09 Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples
Previous Message Josh Berkus 2013-01-10 00:38:36 Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL