Re: libplperl.so and libperl.so - Mailing list pgsql-bugs

From Andrew - Supernews
Subject Re: libplperl.so and libperl.so
Date
Msg-id slrncpkpkd.2njr.andrew+nonews@trinity.supernews.net
Whole thread Raw
In response to libplperl.so and libperl.so  (David Walker <david@cosmicfires.com>)
Responses Re: libplperl.so and libperl.so
List pgsql-bugs
On 2004-11-16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Walker <david@cosmicfires.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

pgsql-bugs by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: BUG #1321: SSL error: sslv3 alert handshake failure
Next
From: Tom Lane
Date:
Subject: Re: libplperl.so and libperl.so