Aighearach has asked for the wisdom of the Perl Monks concerning the following question:

I'm making some functions in postgres using the plperl extention, and I'm having trouble getting everything set up right. I should say to begin with that I am not a C coder, so my level of understanding regarding perl.h and linking issues is pretty low.

To begin with, plperl requires a shared libperl, which perl's Configure tells me can slow down performance. My sollution was to install two perls. This got me part way there. However, it wouldn't compile, and after looking at perl.h and EXTERN.h, I fixed it with a s/errgv/PL_errgv/g and a s/\bna\b/PL_na/g on plperl.c. Which brings us to my first question:

(1) Is this an issue regarding perl version numbers? (I'm using 5.6.0) Is this something I should worry about, or am I just the only person crazy enough to try to compile plperl?

Okay, so then I was able to make plperl, and do a createlang on my database. So far so good. Except that when I try to actually install a plperl function in the database, it gave me an error that it couldn't find libperl.so. This was quite a surprise to me as I had already set LD_LIBRARY_PATH so that it could find it to link plperl.so. So, my next question is:

(2) Is this most likely an issue with perl, plperl, or postgres?

I was able to get it to work by copying libperl.so to /usr/lib, but that is really not where I want it. Which brings us to the important one of my questions, which is:

(3) Will this slow down my existing perl programs and modules, or will this new libperl only get used if I install new modules that are not pure Perl? And, the potentially "noticable effect on performance" mentioned in perl's Configure, what specific aspects of performance would take a hit? This is very important to me in determining if my workarounds are going to be reasonable in a production environment. ie, if performance hit is acceptable, then I'll not be worried about new addons using the shared libperl. I could do some benchmarking, but I don't know what I should be benchmarking...

Thank you,
Paris

Replies are listed 'Best First'.
Re: libperl.so woes
by nardo (Friar) on May 07, 2001 at 19:32 UTC
    What is the output of ldd /path/to/plperl.so and ldd /path/to/libperl.so?
[reply]

      Ah-ha! Thanks, nardo, looking out the ldd output was just what I needed to get me thinking correctly about the problem. Sure, I set LD_LIBRARY_PATH, which allows me to compile and link, but that doesn't help the postmaster daemon find the file! Setting LD_LIBRARY_PATH in my database daemon start script solved the problem.

      Paris
[reply]
      $ ldd /usr/lib/plperl.so
        /usr/gamesparlor/lib/perl5/5.6.0/i686-linux/auto/Opcode/Opcode
+.so => /usr/gamesparlor/lib/perl5/5.6.0/i686-linux/auto/Opcode/Opcode
+.so (0x40006000)
        libperl.so => /usr/lib/libperl.so (0x40013000)
        libc.so.6 => /lib/libc.so.6 (0x400ce000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

$ ldd /usr/gamesparlor/lib/perl5/5.6.0/i686-linux/CORE/libperl.so 
        libc.so.6 => /lib/libc.so.6 (0x400c4000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

      [download]

      Okay, now if I remove /usr/lib/libperl.so I can get: 

      $ ldd /usr/lib/plperl.so
        /usr/gamesparlor/lib/perl5/5.6.0/i686-linux/auto/Opcode/Opcode
+.so => /usr/gamesparlor/lib/perl5/5.6.0/i686-linux/auto/Opcode/Opcode
+.so (0x40006000)
        libperl.so => /usr/gamesparlor/lib/perl5/5.6.0/i686-linux/CORE
+/libperl.so (0x4000b000)
        libc.so.6 => /lib/libc.so.6 (0x400ce000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

      [download]

      but when I try to use a plperl function I get: 

      SELECT totalcomp(5,6);
ERROR:  Load of file /usr/lib/plperl.so failed: libperl.so: cannot ope
+n shared object file: No such file or directory

      [download]
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom