Re: plperl failure on OS X 10.5(.1) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plperl failure on OS X 10.5(.1)
Date
Msg-id 15411.1195671052@sss.pgh.pa.us
Whole thread Raw
In response to Re: plperl failure on OS X 10.5(.1)  (Brandon Maust <bmaust@u.washington.edu>)
Responses 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>)
List 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 by date:

Previous
From: Brandon Maust
Date:
Subject: Re: plperl failure on OS X 10.5(.1)
Next
From: "Kevin Grittner"
Date:
Subject: Re: VACUUM/ANALYZE counting of in-doubt tuples