Re: 8.1RC1 fails to build on OS X (10.4)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Idar Tollefsen <idart(at)performancedesign(dot)no>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.1RC1 fails to build on OS X (10.4)
Date: 2005-11-02 22:53:48
Message-ID: 10482.1130972028@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Idar Tollefsen <idart(at)performancedesign(dot)no> writes:
> *blush* Found it.

> Any one the following flags will produce the described problems (alone
> or in combination):
> -faltivec
> -mabi=altivec
> -maltivec
> -mcpu=<your CPU type here>

<spock>Fascinating.</spock>

I tried this on my own machine, and found out that -faltivec causes
Darwin's gcc to add about a dozen predefined macros (compare -dM output
with and without it). The gem that's killing us is

#define bool bool

but it tromps on user identifier space in some other ways too, including
#define'ing "pixel" and "vector".

I cannot imagine any sane use for a macro defined as above, so I'd
suggest filing a bug report with Apple.

We could kluge our way around this with something like
#ifdef __APPLE_CC__
#undef bool
#endif
in c.h, but I'm a little worried what impact this might have on the
system header files. Why in the world have they got it doing that?

Meanwhile, this is a good tip to have in our archives.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2005-11-02 22:56:17 Re: [HACKERS] Reducing the overhead of NUMERIC data
Previous Message Jim C. Nasby 2005-11-02 22:51:54 Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags