Bug 162198
Summary: | Shared Object Issues when Loading PL/Perl | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pete Toscano <shubnub> |
Component: | postgresql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | hhorak, perl-devel, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-10-04 23:17:00 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pete Toscano
2005-06-30 19:14:02 UTC
The problem is that the dynamic loader is not finding libperl.so; which is not too amazing because the perl package puts libperl.so in a pretty nonstandard place, such as /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so Ordinarily I'd expect the perl package to have hacked /etc/ld.so.conf to put that directory into the search path, but it seems it doesn't do that. Warren, am I supposed to add an rpath to the plperl.so file to find libperl.so? I thought our packaging policy generally frowns on using rpath. In the meantime, Pete, hacking /etc/ld.so.conf is certainly your best short-term workaround. Confirmed. This fix works. Adding a file with the path to my libperl.so to a new file in /etc/ld.so.conf.d and running ldconfig fixed the immediate problem. Thanks Our modern distributions contain explicit symlinks for compatibility with known binary compatible versions of perl, so stuff built with that kind of out-of-the-way RPATH are not likely to break unless the symlinks are explicitly removed in a later version of the perl package. I don't know why it was done this way originally. Maybe to allow multiple versions of perl to be installed simultaneously and avoid links from using the wrong libperl.so? If this is the case, then it probably made sense during the transitions from earlier perl major versions. RPATH to the full path of the libperl.so that was available during build time seems to be what everything else that links against libperl.so does? rpath added in postgresql-8.0.4-2.FC4.1. |