libplperl.so and libperl.so

Your name : David Walker
Your email address : david(at)cosmicfires(dot)com

System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel PII(Linux) and Intel
PPro(FBSD)

Operating System (example: Linux 2.4.18) : Linux 2.6.9 & FreeBSD
4.10-RELEASE-p3

PostgreSQL version (example: PostgreSQL-7.4.6) : PostgreSQL-7.4.6

Compiler used (example: gcc 2.95.2) : Linux: gcc version 3.3.4
FreeBSD: gcc version 2.95.4 20020320

Please enter a FULL description of your problem:
------------------------------------------------

If PostgreSQL is compiled with PL/Perl enabled and linked against Perl
compiled with libperl.so rather than libperl.a, then when postmaster tries to
load libplperl.so, libperl can't be found (Linux, one version of Perl
installed) or is linked with the wrong version of Perl (FreeBSD system Perl in
/usr and ports Perl in /usr/local).

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

Compile PostgreSQL with PL/Perl enabled and linked against Perl compiled with
libperl.so. Run "createlang plperl test" (assuming you have a database named
"test").
The command will fail with or "libperl.so not found" "Symbol not found".

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

This problem occurs because the library path to libperl.so is not included in
libplperl.so.

This patch to postgresql-7.4.6/config/perl.m4 fixes the problem:

*** postgresql-7.4.6/config/perl.m4 Sat Nov 13 12:03:28 2004
--- postgresql-7.4.6-orig/config/perl.m4 Tue May 28 09:57:53 2002
***************
*** 30,35 ****
AC_MSG_CHECKING(for flags to link embedded Perl)
pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
! perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//"`
AC_SUBST(perl_embed_ldflags)dnl
AC_MSG_RESULT([$perl_embed_ldflags])])
--- 30,35 ----
AC_MSG_CHECKING(for flags to link embedded Perl)
pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
! perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
AC_SUBST(perl_embed_ldflags)dnl
AC_MSG_RESULT([$perl_embed_ldflags])])

Thanks to AndrewSN in #postgresql on FreeNode for figuring out how to fix this.

David Walker
--------
http://howto.mainstreamlinux.com

David Walker <david(at)cosmicfires(dot)com> writes:
> This patch to postgresql-7.4.6/config/perl.m4 fixes the problem:

Don't you think this is likely to break more cases than it fixes?
You can't just arbitrarily say that no one else is going to need
the ccdlflags.

On the two platforms I checked it on, it seemed that the ccdlflags
were a strict subset of what was in the ldopts result, so the
proposed patch would make no difference, but I can't feel comfortable
that it's true in general. (If it *is* true in general, then why
does the patch fix your problem?)

regards, tom lane

On 2004-11-16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Walker <david(at)cosmicfires(dot)com> writes:
>> This patch to postgresql-7.4.6/config/perl.m4 fixes the problem:

(The patch in question is based on suggestions of mine made in IRC, so I'll
comment on the technical details)

> Don't you think this is likely to break more cases than it fixes?
> You can't just arbitrarily say that no one else is going to need
> the ccdlflags.

The original configure script is _removing_ the contents of Config{ccdlflags}
from ExtUtils::Embed's output. The problem with this is that it removes a
flag which is necessary to locate the correct perl library on more or less
any system with dynamically-linked libperl. When perl is not dynamically
linked, then ExtUtils::Embed does not include those flags in the first place.

As I originally said in IRC, I do not know why the configure script is
trying to second-guess the ExtUtils::Embed output; however, what it is
doing clearly produces the wrong results.

> On the two platforms I checked it on, it seemed that the ccdlflags
> were a strict subset of what was in the ldopts result, so the
> proposed patch would make no difference, but I can't feel comfortable
> that it's true in general. (If it *is* true in general, then why
> does the patch fix your problem?)

You're not correctly understanding what it does.

Perhaps it would be clearer if you remove the temp vars and just set
perl_embed_ldflags to the output of `perl -MExtUtils::Embed -e ldopts`.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
> On 2004-11-16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Don't you think this is likely to break more cases than it fixes?

> You're not correctly understanding what it does.

Doh. You're right, I misread the (unnecessarily obscure) sed command.

> As I originally said in IRC, I do not know why the configure script is
> trying to second-guess the ExtUtils::Embed output; however, what it is
> doing clearly produces the wrong results.

I'm not sure why it's doing that either; taking the Embed output as gospel
would seem like a reasonable thing to do. But I'm hesitant to change code
that's been the same since PG 7.3 and therefore has survived two port
testing cycles without previous complaints.

Peter, it was you that committed the current contents of config/perl.m4;
do you recall why it wants to remove ccdlflags from the Embed results?

regards, tom lane

On 2004-11-16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
>> As I originally said in IRC, I do not know why the configure script is
>> trying to second-guess the ExtUtils::Embed output; however, what it is
>> doing clearly produces the wrong results.
>
> I'm not sure why it's doing that either; taking the Embed output as gospel
> would seem like a reasonable thing to do. But I'm hesitant to change code
> that's been the same since PG 7.3 and therefore has survived two port
> testing cycles without previous complaints.

It builds on a stock FreeBSD-4 (no ports) only because the system libperl
happens to be in an accessible directory. It fails on FreeBSD-4 with perl
installed from ports (an increasingly common scenario as the system perl
got further behind). The original poster reported it also failing on Linux.

Without a dynamic libperl it builds OK since ccdlflags doesn't appear in
ldopts in that case.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Tom Lane wrote:
> Peter, it was you that committed the current contents of
> config/perl.m4; do you recall why it wants to remove ccdlflags from
> the Embed results?

The ldopts value contains compiler-specific shared library linking flags
plus information about additional library to link in. The ccdlflags
value contains only the compiler-specific shared library linking flags.
If we subtract the second from the first, we get the information about
additional library to link in, which is what we wanted to get out of
it.

The poster apparently needs the rpath information, but I think he'll
have to get that some other way.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The ldopts value contains compiler-specific shared library linking flags
> plus information about additional library to link in. The ccdlflags
> value contains only the compiler-specific shared library linking flags.
> If we subtract the second from the first, we get the information about
> additional library to link in, which is what we wanted to get out of
> it.

[ thinks ... ] OK, so the problem case is where perl was built with a
different compiler than we're building PG with, and hence ccdlflags
may contain incompatible switches. That's a fair point, though it seems
like a shaky assumption that the rest of ldopts isn't also compiler-
specific.

> The poster apparently needs the rpath information, but I think he'll
> have to get that some other way.

Where would he get it from, then? We did talk about providing macros
for more flexible specification of rpath, so we can fix the problem if
we can get the Perl library path, but I'm unsure where to learn that.

regards, tom lane

On 2004-11-16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> The ldopts value contains compiler-specific shared library linking flags
>> plus information about additional library to link in. The ccdlflags
>> value contains only the compiler-specific shared library linking flags.
>> If we subtract the second from the first, we get the information about
>> additional library to link in, which is what we wanted to get out of
>> it.

Why? The ldopts value is intended to be the flags needed for linking a
program that embeds the perl interpreter, which is what you are doing.
What is the point in trying to second-guess what the flags mean?

> [ thinks ... ] OK, so the problem case is where perl was built with a
> different compiler than we're building PG with,

Which is a non-starter in any event - you can't reliably embed perl into a
program that's compiled with a different compiler than perl was, and I doubt
that you could successfully build libplperl with a different compiler to the
rest of PG and still get it to work.

> Where would he get it from, then? We did talk about providing macros
> for more flexible specification of rpath, so we can fix the problem if
> we can get the Perl library path, but I'm unsure where to learn that.

Oddly enough, that's what ccdlflags is for. So you'd end up removing that
info from ldopts only to add it back... which seems somewhat pointless to
me.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
> On 2004-11-16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> [ thinks ... ] OK, so the problem case is where perl was built with a
>> different compiler than we're building PG with,

> Which is a non-starter in any event - you can't reliably embed perl into a
> program that's compiled with a different compiler than perl was,

It's always worked for me on my standard test platform (HPUX, vendor's
cc versus gcc) and if you plan to break it you'd better have a darn
good reason why.

>> Where would he get it from, then? We did talk about providing macros
>> for more flexible specification of rpath, so we can fix the problem if
>> we can get the Perl library path, but I'm unsure where to learn that.

> Oddly enough, that's what ccdlflags is for. So you'd end up removing that
> info from ldopts only to add it back... which seems somewhat pointless to
> me.

No, ccdlflags is some random compiler flags that might or might not
contain an rpath spec, and even if they do it's not clear how to extract
the actual path therefrom...

regards, tom lane