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 14:56:58 |
Message-ID: | 50EED6BA.10507@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/09/2013 10:48 PM, Tom Lane wrote:
> I wrote:
>> Done, we'll soon see how much the buildfarm likes it.
> Well, okapi (Gentoo) doesn't like it:
>
> configure:29191: checking for libperl
> configure:29217: icc -o conftest -O3 -xSSSE3 -parallel -ip -mp1 -fno-strict-aliasing -g -I/usr/lib64/perl5/5.12.4/x86_64-linux/CORE -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et conftest.c -Wl,-O1 -Wl,--as-needed -L/usr/lib64/perl5/5.12.4/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc -lxslt -lxml2 -lssl -lcrypto -lkrb5 -lz -lreadline -lcrypt -lm >&5
> ld: conftest: hidden symbol `pthread_atfork' in /usr/lib64/libpthread_nonshared.a(pthread_atfork.oS) is referenced by DSO
> ld: final link failed: Bad value
>
> The previous successful build on that box shows that plperl was linked
> like this without any error:
>
> icc -O3 -xSSSE3 -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -shared -o plperl.so plperl.o SPI.o Util.o -L../../../src/port -Wl,-rpath,'/usr/lib64/perl5/5.12.4/x86_64-linux/CORE',--enable-new-dtags -Wl,-O1 -Wl,--as-needed -L/usr/lib64/perl5/5.12.4/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc
>
> 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. If so, this idea is a failure and we're gonna have
> to remove the link test, because there is no way I'm going to try to put
> enough smarts into the configure script to do a shared-library link
> correctly.
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.
>
> However, I don't know Gentoo at all, and it may be there's some other
> explanation that we could cope with more readily. Thoughts?
Maybe we need a test that mirrors our use of PERL_SYS_INIT3?, something
like:
#include <EXTERN.h> /* from the Perl distribution */
#include <perl.h> /* from the Perl distribution */
static PerlInterpreter *my_perl; /*** The Perl interpreter ***/
int main(int argc, char **argv, char **env)
{
#if defined(PERL_SYS_INIT3) && !defined(MYMALLOC)
PERL_SYS_INIT3(&argc,&argv,&env);
#endif
my_perl = perl_alloc();
}
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`
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-01-10 16:14:28 | Re: in-catalog Extension Scripts and Control parameters (templates?) |
Previous Message | Marko Tiikkaja | 2013-01-10 14:24:42 | Re: pg_dump --pretty-print-views |