Re: solaris 10 with gcc 3.3.2 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: solaris 10 with gcc 3.3.2
Date
Msg-id 28304.1103349605@sss.pgh.pa.us
Whole thread Raw
In response to Re: solaris 10 with gcc 3.3.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: solaris 10 with gcc 3.3.2  (Mike Mascari <mascarm@mascari.com>)
List pgsql-bugs
I wrote:
> This is standard practice for gcc: it tries to use "cleaned up" versions
> of system headers that will not elicit useless warnings from gcc.  It's
> a good idea, actually, because the degree of insanity in vendor-supplied
> system headers is pretty depressing.  But if the gcc install process
> generated an invalid "cleanup" file then you need to take that up with
> the gcc boys, not us.

On rereading this, a nearly-dead neuron fired --- I have seen problems
of this sort arise when someone took a gcc installation generated on
NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1,
or indeed any release other than M.N.  Then you have a situation where
gcc is inserting cleaned-up versions of some system headers but not
others (because it doesn't force the issue when it doesn't have to),
and if the vendor did something like move a typedef from one header
to another, you lose, because the cleaned-up headers are not in sync
with the others.

In short ... where'd you get your gcc installation from?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: syntax error causes crafted data to be executed in shell
Next
From: Tony Caduto
Date:
Subject: Postgresql 8.0 RC1 not using indexes