Re: [HACKERS] pl/perl extension fails on Windows
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pl/perl extension fails on Windows |
Дата | |
Msg-id | 6805.1500994804@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pl/perl extension fails on Windows (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] pl/perl extension fails on Windows
Re: [HACKERS] pl/perl extension fails on Windows |
Список | pgsql-hackers |
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). regards, tom lane
В списке pgsql-hackers по дате отправления: