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



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

David Walker <david (AT) cosmicfires (DOT) com> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On 2004-11-16, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
(The patch in question is based on suggestions of mine made in IRC, so I'll
comment on the technical details)

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.

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Andrew - Supernews <andrew+nonews (AT) supernews (DOT) com> writes:
Doh. You're right, I misread the (unnecessarily obscure) sed command.

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On 2004-11-16, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
[ 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.

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
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/


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On 2004-11-16, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
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?

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.

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Andrew - Supernews <andrew+nonews (AT) supernews (DOT) com> writes:
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.

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org