Re: PL/perl should fail on configure, not make
От | Andrew Dunstan |
---|---|
Тема | Re: PL/perl should fail on configure, not make |
Дата | |
Msg-id | 50EDE5EA.909@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 04:12 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 01/09/2013 10:16 AM, Tom Lane wrote: >>> Actually, if we were to try to clean this up, I'd suggest moving that >>> logic into the configure script --- it's not apparent to me why it's >>> a good idea to be changing configure-determined values in the Makefile. >>> But in any case this would have to be done by somebody who's in a >>> position to test on affected platforms. >> Here's a patch which does that and produces configure traces like this >> on Mingw: >> checking for Perl archlibexp... C:/Perl/lib >> checking for Perl privlibexp... C:/Perl/lib >> checking for Perl useshrplib... true >> checking for flags to link embedded Perl... -LC:/Perl/lib/CORE -lperl512 >> which seems to be what we want. >> Given that, you should be able to write a reasonably portable configure >> test for library presence. > Looks good. If you're happy with that then I can undertake to add a > libperl.so probe based on AC_TRY_LINK with the unmodified value of > $perl_embed_ldflags. > Go for it. cheers andrew
В списке pgsql-hackers по дате отправления: