Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers