Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group