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

Re: PL/perl should fail on configure, not make

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgbuildfarm(at)jdrake(dot)com
Subject: Re: PL/perl should fail on configure, not make
Date: 2013-01-10 16:38:07
Message-ID: 50EEEE6F.6020404@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/10/2013 11:32 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 01/09/2013 10:48 PM, Tom Lane wrote:
>>> Well, okapi (Gentoo) doesn't like it:
>>> ...
>>> The best guess I can come up with is that this box is only able to link
>>> libperl.so into a shared library, ie the "-fpic -shared" part of the
>>> recipe is critical.
>> This seems fairly unlikely. You're supposed to be able to use it in a
>> standalone executable - see the perlembed manpage. But I guess with
>> Gentoo anything is possible.
> It seemed pretty silly to me too.  After posting it occurred to me that
> maybe the problem wasn't from libperl but one of the other LIBS that
> configure dredges up, but my fix along that line hasn't helped.  So
> I don't know what to think, other than that Gentoo is fragile as can be.
>
>> Maybe we need a test that mirrors our use of PERL_SYS_INIT3?
> I don't know what PERL_SYS_INIT3 expands to, but it's hard to see how it
> would expand to something that would fix this.  The problem looks to be
> that something is pulling in libpthread and getting the wrong version.
>
>> Or maybe for a standalone executable we need to use the ccopts as
>> suggested by the perlembed manpage:
>>       cc -o interp interp.c `perl -MExtUtils::Embed -e ccopts -e ldopts`
> Hm.  It would be interesting to see what ccopts expands to, but if you
> compare the command configure issued with the previous successful link
> of plperl, there's nothing missing that ccopts would be likely to
> supply.
>
> 			

Without access to the machine it's pretty hard to know, so I was just 
speculating fairly wildly. If Jeremy can find out what the problem is 
that would be good, or if he can give us access to the machine it 
shouldn't be terribly hard to get to the bottom.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2013-01-10 16:51:44
Subject: Re: pg_dump --pretty-print-views
Previous:From: Tom LaneDate: 2013-01-10 16:32:35
Subject: Re: PL/perl should fail on configure, not make

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