Re: [HACKERS] pl/perl extension fails on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pl/perl extension fails on Windows
Date
Msg-id 6805.1500994804@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pl/perl extension fails on Windows  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] pl/perl extension fails on Windows
Re: [HACKERS] pl/perl extension fails on Windows
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pl/perl extension fails on Windows
Next
From: Craig Ringer
Date:
Subject: [HACKERS] Re: [SQL] Postgresql “alter column type” creates an event which contains “temp_table_xxx”