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

Re: libplperl.so and libperl.so

From: Andrew - Supernews <andrew+nonews(at)supernews(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: libplperl.so and libperl.so
Date: 2004-11-16 22:00:02
Message-ID: slrncpku32.2njr.andrew+nonews@trinity.supernews.net (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2004-11-16 22:25:29
Subject: Re: pg_dumpall (7.3) 'public' schema bug
Previous:From: Simon RiggsDate: 2004-11-16 21:45:15
Subject: Re: BUG #1320: 7.3.8 server RPM has file error

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