On Mon, 11 Jun 2001, Stephen J. Turnbull gibbered:
>>>>> "Nix" == Nix
>> - and GCC won't see the fix, or will barf in OTHER strange ways
>> because it's got out-of-sync headers.
Nix> It will give you a perfectly clear warning regarding outdated
Nix> fixed headers as of GCC 3. (This area was lacking before
Nix> that, to be sure.)
But this is Valdis's entire complaint, AFAICT. It's certainly mine.
And mine, for what it's worth. It damned well should always have
emitted a warning when an outdated fixed header was used.
GCC fixes (mostly) and breaks (altogether too often) a user's
without telling him about it.
Breakage is, of course, a bug. It happens :( it's fairly rare in my
experience, but then I'm normally using rather aged boxes, and it's
newer OS releases that cause breakage (and fixincludes is not the only
"As of GCC 3" is basically pleading nolo contendere, IMHO.
It's due out on Friday; it's not as though I'm saying `sometime in the
future it will...'; rather `it already does but you asked the question a
week too early'. (But this will not help everyone using earlier GCC's
until they upgrade, of course.)
Nix> (But this is all offtopic for xemacs-beta anyway.)
Unfortunately, it is not. The report that started this thread came to
us. In particular, ME PERSONALLY. Not to bug-gcc.
Oops :( All I can suggest is mentioning the incorrect fix to the GCC
list, really :(
Fixed headers are a kludge, but they're the best of a bad bunch of
possible options (the only other ones are `fall over when perfectly
valid programs are compiled, because of buggy vendor headers' (which is
of course not on) and `don't support systems with buggy vendor headers'
(which rules out 95% of the proprietary Unix OSes out there).
Probably the biggest problem with fixed headers is that in the past some
of the fixes have been rather too wide-ranging, and tended to pick up
dozens of headers with nothing actually wrong with them (because they
were exclusively regex-driven, once, so they couldn't e.g. spot comments
properly). This, again, is much less the case in GCC 3, and in fact it's
my unsupported impression that it's much less a problem in gcc-2.95 than
in earlier releases. Certainly egcs-1.0.x had the habit of fixing the
world when the world had nothing wrong with it...
I don't have time or access to all the platforms where GCC does
kind of thing (I develop on Linux).
fixincludes is run on Linux, because of bugs in some glibc releases.
If it comes down to me answering
the question, I'm not going to read GCC docs and/or sources, I'm going
to say "Not Linux or *BSD? The first thing to try is a non-GCC compiler."
It's my impression that many of them are too broken to bother
with. Certainly given the choice between, say, HP's compiler and GCC I'd
leap at GCC. (DEC's compiler in OSF/1 and Tru64 is very nice, though; I
prefer it to GCC on OSF/1 boxes.)
I'm sure that makes GCC developers unhappy, though. Pity, that.
not clear to me that being in a position where I feel it appropriate
to recommend avoiding GCC on many platforms is good for XEmacs, either.
You could have configure.in print out a warning about possible fixed
header problems if GCC<3 was being used on all platforms except for
DG/UX, Interix, IRIX, Dynix/PTX, sco-*, NT, GNU (Linux and the HURD),
and perhaps the BSDs. (Except for the BSDs, those platforms have a small
set of hardwired fixes rather than the 68K list applied to other
I think fixed headers suck, too. I also think that they, or something
like them, are unavoidable if GCC is to support anywhere near as many
systems as it does without spamming the user with scads of incorrect
warnings and gratuitous errors and failures arising from brokennesses in
the vendor includes. Still, at least they're self-contained (in the
FWIW the person to send new fixes to, or to notify of fixes that are
biting where they should not, is Bruce Korb <bkorb(a)gnu.org>.
`"This code is gross!" meaning "This code has over 144 compilation
--- Correct use of English, from jer