Re: [HACKERS] pl/perl extension fails on Windows

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pl/perl extension fails on Windows
Дата
Msg-id 20729.1501039314@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  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Based on discussion downthread, it seems like what we actually need to
> do is update perl.m4 to extract CCFLAGS.  Turns out somebody proposed
> a patch for that back in 2002:
> https://www.postgresql.org/message-id/Pine.LNX.4.44.0211051045070.16317-200000%40wotan.suse.de
> It seems to need a rebase.  :-)

Ah-hah, I *thought* we had considered the question once upon a time.
There were some pretty substantial compatibility concerns raised in that
thread, which is doubtless why it's still like that.

My beef about inter-compiler compatibility (if building PG with a
different compiler from that used for Perl) could probably be addressed by
absorbing only -D switches from the Perl flags.  But Peter seemed to feel
that even that could break things, and I worry that he's right for cases
like -D_FILE_OFFSET_BITS which affect libc APIs.  Usually we'd have made
the same decisions as Perl for that sort of thing, but if we didn't, it's
a mess.

I wonder whether we could adopt some rule like "absorb -D switches
for macros whose names do not begin with an underscore".  That's
surely a hack and three-quarters, but it seems safer than just
absorbing everything willy-nilly.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] pl/perl extension fails on Windows
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Inadequate infrastructure for NextValueExpr