Re: [PATCH] PR15824: Broken configure test in libcpp

[Zack Weinberg <zack at codesourcery dot com>]

Roger Sayle <roger@eyesopen.com> writes:

> The following patch resolves PR preprocessor/15824 which is caused
> by a broken "configure" test for HAVE_UCHAR which is fallout from
> the move of libcpp to it's own top-level directory.
>
> The problem is that configure tests in the gcc/ directory can
> rely the configure script to have correctly initialized CFLAGS
> to find "ansidecl.h" in the top-level include directory, and
> a generated "system.h" in the current directory.  Unfortunately,
> the same AC_TRY_COMPILE test when moved to libcpp's configure
> fails to find both of these.  The fact that this test has been
> failing unconditionally on all platforms for some time has been
> hidden by the fact that on most platforms HAVE_UCHAR is supposed
> to be false.  On Tru64 and AIX, however, the inability to define
> HAVE_UCHAR results in compiler warnings and even bootstrap failures.
>
> My suggested fix below is to completely ignore "ansidecl.h" and
> the not yet generated "system.h", and directly include <sys/types.h>
> as described in this test's commentary.  If sys/types.h doesn't
> exist, we're no worse off than we currently are, but on AIX and
> Tru64, this simplified test is sufficient to do the right thing.
>
>
> The following patch has been tested on both powerpc-ibm-aix5.2.0.0
> and alphaev67-dec-osf5.1 with a top-level "make", and checking
> libcpp/config.h manually that HAVE_UCHAR is now correctly defined.
>
> Ok for mainline?

Yes, this is OK.  I worry a little about systems where some other
header is the one that defines uchar, but let's cross that bridge when
we discover it.

zw