Re: PL/perl should fail on configure, not make
От | Andrew Dunstan |
---|---|
Тема | Re: PL/perl should fail on configure, not make |
Дата | |
Msg-id | 50EED6BA.10507@dunslane.net обсуждение исходный текст |
Ответ на | Re: PL/perl should fail on configure, not make (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PL/perl should fail on configure, not make
|
Список | 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 thePerl 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
В списке pgsql-hackers по дате отправления: