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

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.

regards, tom lane