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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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 03:48:10
Message-ID: 14053.1357789690@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

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?

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2013-01-10 04:02:54
Subject: Re: Lock levels for ALTER TABLE
Previous:From: Jeff JanesDate: 2013-01-10 03:46:01
Subject: Re: Further pg_upgrade analysis for many tables

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