Re: address@hidden: 21.2.90: configure problems -- using gcc 3.1 and --x-includes option]

[Richard Stallman]

    Actually, no: the problem report came from a pretester of Emacs 21.2.90, 
    which is produced from the release branch.  The release branch uses 
    Autoconf 2.13, the one we used in Emacs 21.1.

Let's try generating it with Autoconf 2.5X, then, and see if that
solves the problem.  If the problem is already solved, we don't
have to wrestle with it any more.

    > You're worried about some random version of GCC issuing warnings when
    > #include fails; I'm not.  Me, I'd just ignore the warnings.

    You can't do that when the very point of the test is to check whether
    a particular header file is present, or defines a certain macro.

I think I see a miscommunication here.  Failure to find a certain
header file normally results in an *error*.  Autoconf needs to notice
these *errors*, but it could ignore mere *warnings*.

I think one person raised the question of whether this case might, in
some GCC version, result only in a warning.  That would be a bug, and
we have no reason to think any version DID have that bug.

    Can you say this with 100% certainty about every single version of GCC
    ever released?

100% certainty is too much to ask for.  Versions of GCC more than 5
years old are rarely used.  We have no reason to think that any of
these old versions had such a fault; it is merely that we do not know
for certain that they did not.

If there is a small chance that some old GCC version peculiarly failed
to report failing #include as an error, that may be a lesser risk than
the present problem, which certainly can happen.

    True, but in some cases the GCC warning indicates a misconfiguration
    by the person running "configure", and this misconfiguration can cause
    code to be silently miscompiled if the warning is ignored.  I don't
    see any easy way for Autoconf to determine automatically whether the
    misconfiguration is serious enough to be one of real concern.

Nobody is asking for Autoconf to determine this.  We're only asking
for Autoconf to be able to do what it used to do -- determine whether
certain header files are available, for instance -- without being
confused by these new warning messages.

      If -I changes a directory from the
    implicit system status to non-system status, GCC warns, but complies.

If so, one simple way to fix the present bug is to delete that warning
feature.  Is this feature important enough to be worth preserving
when it causes trouble?

    If things break because of that, it's the user's problem.

With all due respect, that is the wrong attitude for the job of
maintaining GCC or Autoconf.

This problem is not the user's fault; he did not do anything that
should have provoked a problem as severe as he got.  That -I option
may have been potentially wrong, but practically speaking it would
have caused no problem if only he were using an older version of GCC
which never made this warning.

    I can think of a way that GCC might help out here.  GCC might warn
    about the included file only if the file's interpretation is affected
    by whether or not it is treated as a system include file.

Warning only if GCC uses the file in a way that depends on whether
it was a system header file or not could be a good idea.

    > As for configury bloat, we're way past that point; the sripts are huge
    > and slow.

    This doesn't make we should gratuitously make them bigger and slower.

Fixing a bug is not a gratuitous change.
This is a serious bug and it needs to be fixed.

If it isn't fixed already, that is.