This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] parallel build fix in libiberty
- To: "J. Johnston" <jjohnstn at cygnus dot com>
- Subject: Re: [PATCH] parallel build fix in libiberty
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Fri, 27 Jul 2001 18:20:11 +0200 (CEST)
- cc: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>, <gcc-patches at gcc dot gnu dot org>, Jeff Johnston <jjohnstn at redhat dot com>
On Fri, 27 Jul 2001, J. Johnston wrote:
> Can you post the lines containing HAVE_WCHAR_H, HAVE_WCTYPE_H, and
> HAVE_BTOWC from the config.h file in your libiberty build directory?
Of course:
/* Define if you have the <wchar.h> header file. */
#define HAVE_WCHAR_H 1
/* Define if you have the <wctype.h> header file. */
#define HAVE_WCTYPE_H 1
/* Define if you have the btowc function. */
/* #undef HAVE_BTOWC */
I believe the problem is
# if !defined _LIBC
typedef unsigned long int uintptr_t;
# endif
in libiberty/regex.c which comes after our #inclusion of
<usr/include/sys/int_types.h> via <usr/include/sys/types.h>.
And int_types.h contains:
/*
* intptr_t and uintptr_t are signed and unsigned integer types large enough
* to hold any data pointer; that is, data pointers can be assigned into or
* from these integer types without losing precision.
*/
#if defined(_LP64) || defined(_I32LPx)
typedef long intptr_t;
typedef unsigned long uintptr_t;
#else
typedef int intptr_t;
typedef unsigned int uintptr_t;
#endif
Unconditionally typedef-ing uintptr_t in application code seems rather
problematic to me.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/