Skip site navigation (1) Skip section navigation (2)

Re: libplperl.so and libperl.so

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: andrew(at)supernews(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: libplperl.so and libperl.so
Date: 2004-11-17 05:24:24
Message-ID: 7308.1100669064@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

pgsql-bugs by date

Next:From: Michael FuhrDate: 2004-11-17 06:24:20
Subject: Re: plperl crashes backend
Previous:From: Tom LaneDate: 2004-11-17 05:14:57
Subject: Re: strange order by behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group