Re: plperl failure on OS X 10.5(.1)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: plperl failure on OS X 10.5(.1)
Дата
Msg-id 15411.1195671052@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: plperl failure on OS X 10.5(.1)  (Brandon Maust <bmaust@u.washington.edu>)
Ответы Re: plperl failure on OS X 10.5(.1)  (Brandon Maust <bmaust@u.washington.edu>)
Re: plperl failure on OS X 10.5(.1)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Brandon Maust <bmaust@u.washington.edu> writes:
> On 21 Nov, 2007, at 08:39 , Tom Lane wrote:
>> Seems the question is not so much about OS X as it is about what
>> perl you're using ...

> it's 5.8.8, as provided by apple (same for gcc, etc):

> perl on OS X does look to be constitutively defining a 'bool' as _Bool  
> via gcc's stdbool.h, so perhaps this is more of a compiler issue?

No, because I see the identical content in stdbool.h on OS X 10.4
(perl 5.8.6) and it is not causing a problem here.  Apparently 5.8.8
is sucking stdbool.h into the compile where 5.8.6 did not.  Can you
track down just what the inclusion path is?

I'm tempted to fix this with

#ifdef bool
#undef bool
#endif

in plperl.h after pulling in the Perl headers.  However, it's not clear
to me why you aren't seeing warnings about "false" and "true" getting
redefined, if stdbool.h is really getting included.

For reference, the interesting part of stdbool.h on 10.4 looks like

#define false   0
#define true    1

#define bool    _Bool
#if __STDC_VERSION__ < 199901L && __GNUC__ < 3
typedef int     _Bool;
#endif

Since this is gcc 3, I suppose that the typedef isn't being used here
but must get supplied internally by the compiler...
        regards, tom lane


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

Предыдущее
От: Brandon Maust
Дата:
Сообщение: Re: plperl failure on OS X 10.5(.1)
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: VACUUM/ANALYZE counting of in-doubt tuples