Re: [HACKERS] pl/perl extension fails on Windows
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] pl/perl extension fails on Windows |
Дата | |
Msg-id | 746dd417-aa4e-b638-6755-70d134532823@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pl/perl extension fails on Windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 07/25/2017 11:00 AM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Perl also has a mechanism for flags added to Configure to be passed >> along when building loadable modules; if it didn't, not just plperl >> but every Perl module written in C would have this issue if any such >> flags where used. >> ... >> While I'm not sure of the details, I suspect that we need to use one >> of those methods to get the CCFLAGS used to build perl, and include >> those when SPI.o, Util.o, and plperl.o in src/pl/plperl. Or at least >> the -D switches from those CCFLAGS. > Hm, I had the idea that we were already asking ExtUtils::Embed for that, > but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds > like a promising avenue to pursue. > > It would be useful to see the results of > > perl -MExtUtils::Embed -e ccopts > > on one of the affected installations, and compare that to the problematic > field(s). -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing -mms-bitfields -I"C:\Perl64\lib\CORE" cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: