Re: Trouble while compiling Xemacs
On Sun, 10 Jun 2001, Valdis Kletnieks gibbered:
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
> silly.
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
Normally that goes `report it to the vendor, vendor ignores you', or, if
you're lucky, `report it to the vendor, vendor says `it's fixed in the
next version' --- and what do we do then? Refuse to support the older
version, when we have a perfectly good (if kludgy) mechanism for
supporting it, after a fashion?
- and GCC won't see the fix, or
will barf
in OTHER strange ways because it's got out-of-sync headers.
It will give you a perfectly clear warning regarding outdated fixed
headers as of GCC 3. (This area was lacking before that, to be sure.)
A case could be made that the 'fixincludes' *hurts* the cause
of
getting header files fixed
You're quite right; it does reduce the incentive to vendors to fix them;
however, if the choice is cleaner vendor headers against people using
older versions of the OS that are incapable of using GCC *just because
of the headers* then I know what I'd rather do.
(Besides, when the vendors *do* fix their headers, those headers are no
longer fixed by GCC.)
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".
Delete the fixincluded headers and you can still do that.
It's a lot harder to get IBM to fix it when the
product
already works around it.
Most of the faults that fixincludes fixes are quite obvious; a diff
between the fixed headers and the unfixed ones might almost be enough
for them. If IBM can't do *that*, I have *no* sympathy. (And I know that
some of them can do that!)
Personally, I'd settle for a --diable-fixincludes flag on the
./configure.
This would, in many cases, prevent GCC from building at all.
(But this is all offtopic for xemacs-beta anyway.)
--
`"This code is gross!" meaning "This code has over 144 compilation
errors."'
--- Correct use of English, from jer