From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19445 invoked by alias); 25 Feb 2003 23:21:42 -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 19438 invoked from network); 25 Feb 2003 23:21:42 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 172.16.49.205 with SMTP; 25 Feb 2003 23:21:42 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h1PNLfa13347 for gdb-patches@sources.redhat.com; Tue, 25 Feb 2003 17:21:41 -0600 Date: Tue, 25 Feb 2003 23:21:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200302252321.h1PNLfa13347@duracef.shout.net> To: gdb-patches@sources.redhat.com Subject: [rfc] configury: CC_HAS_UINTPTR_T X-SW-Source: 2003-02/txt/msg00676.txt.bz2 This is my first 'configure' patch, so I don't expect it to pass on the first draft. If there's anything I need to know about this kind of stuff, tell me please. This patch just adds CC_HAS_UINTPTR_T. After this patch, I'll write patches to procfs.c and gdb_thread_db.h to use the new variable, so that they can put out a more informative compile error than the dreck that they cough up right now. I've seen several reports from the field where this actually happens (pr gdb/660 is one case). If you like CC_HAS_UINTPTR_T, but you don't like the idea of: #if !CC_HAS_UINTPTR_T #error 'Your glibc is so 20th century. Bye bye!' #endif ... then I hope this patch is okay with you. The next patch is the place to debate what actually happens when CC_HAS_UINTPTR_T is not defined. I don't show the diffs to 'configure' because there's 3000 lines of them. I regenerated my 'configure' with a stock autoconf 2.13 from ftp.gnu.org. Testing: I tested this by running it on native i686-pc-linux-gnu. I played with /usr/include/stdint.h so that I could observe both code paths. Comments? Michael C 2003-02-25 Michael Chastain * configure.in: New variable CC_HAS_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 25 Feb 2003 22:08:37 -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 CC_HAS_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 25 Feb 2003 22:08:46 -0000 @@ -689,6 +689,23 @@ 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_c_uintptr_t, +[AC_TRY_RUN([ +#include +int main () { + uintptr_t foo = 0; + return foo; +}], +gdb_cv_c_uintptr_t=yes, gdb_cv_c_uintptr_t=no, gdb_cv_c_uintptr_t=no)]) +AC_MSG_RESULT($gdb_cv_c_uintptr_t) +if test $gdb_cv_c_uintptr_t = yes; then + AC_DEFINE(CC_HAS_UINTPTR_T) +fi + dnl See if compiler supports "long long" type. AC_MSG_CHECKING(for long long support in compiler)