Perl/Postgresql: plperl.so undefined symbol: Perl_sv_2bool_flags

Question

This is my first post on here so sorry if I don't provide all the information required first time round!

My boss and I have been trying to install plperl on our postgres installation on one of our servers (Centos 6.5, Postgres 9.2.1, Perl 5.10.1) and we keep running into the same problem which is as follows:

ERROR:  could not load library "/opt/PostgreSQL/9.2/lib/postgresql/plperl.so": 
/opt/PostgreSQL/9.2/lib/postgresql/plperl.so: undefined symbol: Perl_sv_2bool_flags

This error is returned when we try and install the language (create language plperl;) either through SQL or using the PgAdmin III GUI.

I have checked that we have a lperl.so file in /opt/PostgreSQL/9.2/lib/postgresql/ as well as looking for libperl.so as most posts pertaining to this problem suggest. I have tried placing libperl.so in lots of different places as every man and his dog has a different suggestion as to where it should be placed.

Running ldd /opt/PostgreSQL/9.2/lib/postgresql/plperl.so returns the following:

ldd /opt/PostgreSQL/9.2/lib/postgresql/plperl.so
        linux-vdso.so.1 =>  (0x00007fff2d9b7000)
        libperl.so => /lib64/libperl.so (0x00007f8ab5c11000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8ab59f3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8ab565f000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8ab5445000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f8ab522b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f8ab5027000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f8ab4da3000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8ab4b6b000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f8ab4968000)
        /lib64/ld-linux-x86-64.so.2 (0x00000034aa800000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f8ab46f1000)

I don't think the versions of Postgres and Perl are a problem a we have another server running Centos 6.5, Postgres 9.3 and Perl 5.10.1 with pl/perl running perfectly (I've also tried looking at what's going on there to fix this but cant work it out).

From what I can tell, Postgres is expecting libperl.so to be in /lib64 however when Perl was installed it was installed somewhere else. At the moment Postgres is the only thing which will be using libperl.so

Unfortunately I don't know how everything was installed on this server as my boss set everything up before I joined the company and he has only just decided we actually need to get it working.

From looking at both our servers, I can't see any differences in the installations and configurations which would cause one to work and one to not.

I'm pretty much at my wits end with this (Its the last problem we need to fix with the Postgres install), so any suggestions would be appreciated.

Cheers

You say you have a similar setup on another machine - does `perl -V` show *exactly* the same output? Do you have multiple and different copies of `libperl.so` on the system? — G. Cito, Sep 10 '14 at 16:03
Short version: The module was installed (compiled) using one build of Perl, but it's being used by a different build. — ikegami, Sep 11 '14 at 13:01

G. Cito · Answer 1 · 2014-09-12T14:27:23.170

Are you using binary packages installed with a package manager that properly controls for dependencies? Are compiling the libraries yourself? While it's possible to force binary packages to install with a GUI "admin" tool, or place the files in the location where PostgreSQL will be able to find them, you shouldn't expect them to work properly if they haven't been compiled/linked on reasonably similar platforms.

It looks like you are using a version of Perl that has been compiled with different flags or options than the plperl.so file you are installing. Take a look at the output of perl -V to see how your perl was compiled - consistent use of threading options is important.

What /opt/PostgreSQL/9.2/lib/postgresql/plperl.so is telling you that one of its symbols is undefined. This may be due to compile options or may means you need a newer version of Perl and libperl.so (5.10.1 is quite old). Recent versions of PotgreSQL and plperl usually require a newer version of perl than the one you cite.

libperl.so should be installed in a consistent location for your platform and other applications that have been compiled/linked to use it - you should not need to move it around. Indeed if there are numerous copies of libperl.so on your system plperl may find an outdated version libperl.so when it loads.

For comparison here is the output from the commands you have run on one of my systems:

/usr/local/lib/postgresql/plperl.so:
       libperl.so => /usr/local/lib/perl5/5.16/mach/CORE/libperl.so (0x801214000)
       libthr.so.3 => /lib/libthr.so.3 (0x80158f000)
       libc.so.7 => /lib/libc.so.7 (0x80081b000)
       libm.so.5 => /lib/libm.so.5 (0x8017b2000)
       libcrypt.so.5 => /lib/libcrypt.so.5 (0x8019d3000)
       libutil.so.9 => /lib/libutil.so.9 (0x801bf2000)

The symbol is present:

strings /usr/local/lib/perl5/5.16/mach/CORE/libperl.so | grep 2bool
 Perl_sv_2bool_flags
 Perl_sv_2bool

Most likely somewhere in your stack there is an perl XS module or a .so file pointing to the wrong place. Perhaps there is some confusion at the system level with cached libraries ... I believe ldconfig is the tool you use to manage this on Linux.

Thanks for the speedy reply, I've added some more details which hopefully cast some more light on the problem. I'm a relative newby at all of this (apprentice of 1 year) so I probably wont be able to answer all your questions, but again thanks. — Oliver Wilkinson, Sep 10 '14 at 15:10
Right, So perl -V produces exactly the same output, i've checked that carefully. The only thing I can see now is when running `ldd plperl.so` on both systems, the one which works looks a lot more like your output, as in `libperl.so` is linked to the perl dir, not /lib64/. I'll have a look at using `ldconfig`. Again Cheers! — Oliver Wilkinson, Sep 11 '14 at 08:07
Are there two copies of `libperl.so` on the problem system? If everything but the `libperl.so` files on your two systems is *exactly* the same, then remove `libperl.so` from `/lib64/` (i.e. move it / back it up somewhere) and copy over the working `libperl.so` to the standard `libperl.so` location. This is **NOT** a fix: it is a hackish test to get more information about where the problem is coming from. If you want to maintain and provision your systems properly you need to get them in a known, documented and reproducible state so your package management tools can work as expected. — G. Cito, Sep 12 '14 at 14:41
BTW if `/lib64/libperl.so` was added to your system by your package management tools then you should be able to find out which package installed the file. The command for this would be something like `rpm -qf /lib64/liperl.so` on Centos. — G. Cito, Sep 12 '14 at 14:46

Perl/Postgresql: plperl.so undefined symbol: Perl_sv_2bool_flags

1 Answers1