Peter Eisentraut <peter_e@gmx.net> writes:
> On 1/9/13 7:56 PM, Tom Lane wrote:
>> 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.
> How does this survive a distribution upgrade with a new libperl soname?
Well, I'm not the package maintainer for perl, so this is not an
authoritative answer ... but I don't believe that there's any
expectation that you could replace the installation with a different
major perl version and still have C-level dependencies work. Adding a
soname number wouldn't exactly be enough to fix that type of problem,
anyhow, considering the number of ABI-incompatible ways you can build
libperl.
There is some version dependency checking, all right, but it's done off
of special RPM provides/requires symbols not the library soname. For
instance I see this on a Fedora build of plperl:
$ rpm -qp postgresql-plperl-9.2.2-3.fc16.x86_64.rpm --requires
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libperl.so()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
perl(:MODULE_COMPAT_5.14.3) <-----------------
postgresql-server(x86-64) = 9.2.2-3.fc16
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
I suspect they chose that method so it would do something useful for
Perl extension modules as well as programs that require libperl.
regards, tom lane