On 01/10/2013 11:32 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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