This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR15824: Broken configure test in libcpp
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 23 Nov 2004 23:33:58 -0800
- Subject: Re: [PATCH] PR15824: Broken configure test in libcpp
- References: <Pine.LNX.email@example.com>
Roger Sayle <firstname.lastname@example.org> 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-aix188.8.131.52
> 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.