From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5487 invoked by alias); 26 Feb 2003 01:26:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5480 invoked from network); 26 Feb 2003 01:26:40 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 172.16.49.205 with SMTP; 26 Feb 2003 01:26:40 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h1Q1Qd715234 for gdb-patches@sources.redhat.com; Tue, 25 Feb 2003 19:26:39 -0600 Date: Wed, 26 Feb 2003 01:26:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200302260126.h1Q1Qd715234@duracef.shout.net> To: gdb-patches@sources.redhat.com Subject: [rfa] HAVE_UINTPTR_T X-SW-Source: 2003-02/txt/msg00687.txt.bz2 Draft #2. I changed the variable to HAVE_UINTPTR_T, and I changed AC_TRY_RUN to AC_TRY_COMPILE. I re-tested with and without uintptr_t in /usr/include/stdint.h to hit both paths. I don't show diffs for regenerated 'configure'. I regenerated 'configure' with stock autoconf 2.13 from ftp.gnu.org. Again, this is so that the gdb build can do something better when it needs uintptr_t and doesn't have it (pr gdb/660). My notion of 'something better' is going to be to spit out a better error message, not to actually work. Somebody has to have a really old libc (more than 3 years old) to get this message, but with millions of users, some people do. OK to commit? Michael C 2003-02-25 Michael Chastain * configure.in: New variable HAVE_UINTPTR_T. * config.in: Likewise. * configure: Regenerated. Index: config.in =================================================================== RCS file: /cvs/src/src/gdb/config.in,v retrieving revision 1.53 diff -u -r1.53 config.in --- config.in 14 Feb 2003 20:07:00 -0000 1.53 +++ config.in 26 Feb 2003 01:20:51 -0000 @@ -111,6 +111,9 @@ /* Define if ioctl argument PIOCSET is available. */ #undef HAVE_PROCFS_PIOCSET +/* Define if the C library supports "uintptr_t" type. */ +#undef HAVE_UINTPTR_T + /* Define if the `long long' type works. */ #undef CC_HAS_LONG_LONG Index: configure.in =================================================================== RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.125 diff -u -r1.125 configure.in --- configure.in 20 Feb 2003 23:38:58 -0000 1.125 +++ configure.in 26 Feb 2003 01:20:52 -0000 @@ -689,6 +689,21 @@ fi fi +dnl See if C library supports "uintptr_t" type. +dnl AC_CHECK_TYPE is not enough because this type lives in a header file. + +AC_MSG_CHECKING(for uintptr_t in C library) +AC_CACHE_VAL(gdb_cv_have_uintptr_t, +[AC_TRY_COMPILE([#include ], + [uintptr_t foo = 0; + return foo;], + gdb_cv_have_uintptr_t=yes, + gdb_cv_have_uintptr_t=no)]) +AC_MSG_RESULT($gdb_cv_have_uintptr_t) +if test $gdb_cv_have_uintptr_t = yes; then + AC_DEFINE(HAVE_UINTPTR_T) +fi + dnl See if compiler supports "long long" type. AC_MSG_CHECKING(for long long support in compiler)