Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162198 - Shared Object Issues when Loading PL/Perl
Summary: Shared Object Issues when Loading PL/Perl
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-30 19:14 UTC by Pete Toscano
Modified: 2013-07-03 03:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-10-04 23:17:00 UTC

Attachments (Terms of Use)

Description Pete Toscano 2005-06-30 19:14:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Epiphany/1.6.1

Description of problem:
I'm trying to create a function in the "plperl" language.  In order to use it in my database, I need to create it in that database.  When I try to createlang as the postgres user, I get the following error:

[foo@bar ~]$ createlang -U postgres -d baz plperl
createlang: language installation failed: ERROR:  could not load library "/usr/lib/pgsql/": cannot open shared object file: No such file or directory

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. createdb -U postgres foo
2. createlang -U postgres -d foo plperl

Actual Results:  createlang: language installation failed: ERROR:  could not load library "/usr/lib/pgsql/": cannot open shared object file: No such file or directory

Expected Results:  No error message and a "0" result code.

Additional info:

I tried recompiling PostgreSQL from the SRPM on one of the boxes I'm seeing the error on, but that didn't help.  I verified the error on my laptop.  Plperl did load correctly on an FC2 box I have.

Comment 1 Tom Lane 2005-06-30 22:14:24 UTC
The problem is that the dynamic loader is not finding; which is not
too amazing because the perl package puts in a pretty nonstandard
place, such as
Ordinarily I'd expect the perl package to have hacked /etc/ 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 file to find  I
thought our packaging policy generally frowns on using rpath.

In the meantime, Pete, hacking /etc/ is certainly your best short-term

Comment 2 Pete Toscano 2005-06-30 22:23:13 UTC
Confirmed.  This fix works.  Adding a file with the path to my to a
new file in /etc/ and running ldconfig fixed the immediate problem.


Comment 3 Warren Togami 2005-07-01 02:10:02 UTC
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  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 that was available during build time
seems to be what everything else that links against does?

Comment 4 Tom Lane 2005-10-04 23:17:00 UTC
rpath added in postgresql-8.0.4-2.FC4.1.

Note You need to log in before you can comment on or make changes to this bug.