From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30343 invoked by alias); 19 Oct 2016 15:55:33 -0000 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 Received: (qmail 30319 invoked by uid 89); 19 Oct 2016 15:55:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=phenomenon X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 15:55:23 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 894AF4E13CE6A; Wed, 19 Oct 2016 16:55:16 +0100 (IST) Received: from [10.20.78.157] (10.20.78.157) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Wed, 19 Oct 2016 16:55:19 +0100 Date: Wed, 19 Oct 2016 15:55:00 -0000 From: "Maciej W. Rozycki" To: John Baldwin CC: , Pedro Alves Subject: Re: spurious change regenerating gdb/config.in? In-Reply-To: <5948067.MWKfYDzD67@ralph.baldwin.cx> Message-ID: References: <5948067.MWKfYDzD67@ralph.baldwin.cx> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-10/txt/msg00570.txt.bz2 On Wed, 19 Oct 2016, John Baldwin wrote: > > diff --git c/gdb/config.in w/gdb/config.in > > index c82a5b4..3790d10 100644 > > --- c/gdb/config.in > > +++ w/gdb/config.in > > @@ -453,12 +453,12 @@ > > /* Define to 1 if your system has struct lwp. */ > > #undef HAVE_STRUCT_LWP > > > > -/* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_tdname'. */ > > -#undef HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME > > - > > /* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_syscall_code'. */ > > #undef HAVE_STRUCT_PTRACE_LWPINFO_PL_SYSCALL_CODE > > > > +/* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_tdname'. */ > > +#undef HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME > > + > > /* Define to 1 if your system has struct reg in . */ > > #undef HAVE_STRUCT_REG > > > > > > This is with pristine FSF autoconf 2.64. I suspect this is > > just because the config.in in master was generated by some > > other autoconf version. To confirm, does anyone else > > see this? > > I don't see this, but feel free to fix. It is likely my fault somehow as I > added the associated check. I had used a pristine FSF autoconf (built and > installed to a custom prefix to avoid it using any other autoconf), so I'm > not sure why it is different. FWIW I can reproduce the phenomenon and I can see the ordering of these macros throughout this file being alphabetic by name (with the exception of some stuff inserted with AH_VERBATIM), so it looks to me like such regeneration is indeed due, though I'd consider the issue very minor. Maciej