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
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 |