| 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: | Whole Thread | Raw Message | 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 |