On Sat, 09 Jun 2001 19:32:26 BST, Nix said:
On Thu, 07 Jun 2001, Valdis Kletnieks said:
> /Valdis (who boycotts gcc on platforms that have a vendor compiler, for exactly
> this reason).
It's a strange reason. Avoid GCC on platforms where the vendor compiler
is better and you're not cross-compiling, sure, but `boycotting' it
because of broken vendor headers (i.e. no fault of GCC's!) is just
No, I boycott it because GCC insists on stashing copies of stuff from
/usr/include, which results in strange breakage and failure modes after
patches have been applied. You find a header problem, report it to the
vendor, get a patch, apply it - and GCC won't see the fix, or will barf
in OTHER strange ways because it's got out-of-sync headers.
A case could be made that the 'fixincludes' *hurts* the cause of
getting header files fixed - for instance, IBM *HAS* taken bug
reports on things like /bin/ld that *only* break with gcc, but not
with their compiler. If fixincludes didn't cover up the problem, then
I could tell IBM "This header file has problem XYZ - fix it so GCC will
accept it". It's a lot harder to get IBM to fix it when the product
already works around it.
Personally, I'd settle for a --diable-fixincludes flag on the ./configure.