From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28129 invoked by alias); 15 Nov 2012 14:34:32 -0000 Received: (qmail 27929 invoked by uid 22791); 15 Nov 2012 14:34:30 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 14:34:21 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFEYIBf024326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 09:34:18 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAFEYHbZ016121; Thu, 15 Nov 2012 09:34:17 -0500 Message-ID: <50A4FD68.5080006@redhat.com> Date: Thu, 15 Nov 2012 14:34:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Pierre Muller CC: gdb-patches@sourceware.org Subject: Re: [RFA] Remove AC_HEADER_STAT from configure.ac References: <50a4aadb.c54c420a.715f.5d53SMTPIN_ADDED@mx.google.com> <50A4C0C5.8020901@redhat.com> <000301cdc33c$f4203d20$dc60b760$@muller@ics-cnrs.unistra.fr> In-Reply-To: <000301cdc33c$f4203d20$dc60b760$@muller@ics-cnrs.unistra.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00400.txt.bz2 On 15-11-2012 14:24, Pierre Muller wrote: > Hi Pedro, > > I tried to do the AC_HEADER_STAT removal patch... >> >> When moving headers to common/, we need to ensure that whatever config.h >> HAVE_FOO symbols they are using are also produced by gdbserver's configure >> too. > > Didn't know about this... Seems like I underestimated > the complexity. > >> gdb_wait.h seems to depend on AC_CHECK_HEADERS checks for sys/wait.h and >> wait.h. gdbserver's configure only checks the former. > > Would adding wait.h to the gdbserver configure be enough for this > problem? Yes. >> gdb_stat.h seems to depend on AC_HEADER_STAT for STAT_MACROS_BROKEN. >> gdbserver's configure doesn't call that macro. But, according to > autoconf's >> manual: >> >>> Macro: AC_HEADER_STAT >>> >>> If the macros S_ISDIR, S_ISREG, etc. defined in sys/stat.h do not work >> properly >>> (returning false positives), define STAT_MACROS_BROKEN. This is >>> the case on Tektronix UTekV, Amdahl UTS and Motorola System V/88. >>> >>> This macro is obsolescent, as no current systems have the bug. New >>> programs need not use this macro. >> >> These old hosts are not relevant for GDB anymore (I found references to >> Motorola 88000 but support was removed on 6.0). So we can just remove >> the AC_HEADER_STAT call from gdb's configure.ac, and remove the whole >> STAT_MACROS_BROKEN block from gdb_stat.h. That would be done as a > separate >> patch (in a separate email thread). I'd prefer that be done before the >> move, thus avoiding adding AC_HEADER_STAT to gdbserver. > > I tried... > Here is the result. > Should we add stat.h to the list of checked headers? No need. gdb_stat.h includes sys/stat.h unconditionally. > I didn't find any HAVE_STAT_H occurrence, > and thus assumed this was unnecessary. > PS: In the regenerated files, > I discovered that configure has a strange, apparently unrelated > change... Is this normal? No. I just tried regenerating configure in the current mainline, with no changes to configure.ac, and configure did not change for me. Be sure to use pristine FSF autoconf 2.64. Sounds like the autoconf you used has local mingw patches. > 2012-11-15 Pierre Muller > > * configure.ac (AC_HEADER_STAT): Remove. > * gdb_stat.h (STAT_MACROS_BROKEN): Remove macro use > and corresponding code. > * configure: Regenerate. Otherwise this is fine. Thanks. -- Pedro Alves