From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47645 invoked by alias); 19 Oct 2016 13:09:51 -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 47357 invoked by uid 89); 19 Oct 2016 13:09:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Was, Hx-languages-length:2022 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 13:09:39 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 558B9C04B317; Wed, 19 Oct 2016 13:09:38 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9JD9bO5003317; Wed, 19 Oct 2016 09:09:37 -0400 Subject: Re: spurious change regenerating gdb/config.in? To: John Baldwin , gdb-patches@sourceware.org References: <5948067.MWKfYDzD67@ralph.baldwin.cx> From: Pedro Alves Message-ID: <47b926c4-7191-7f6d-30d2-e36e148d7a5f@redhat.com> Date: Wed, 19 Oct 2016 13:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5948067.MWKfYDzD67@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00566.txt.bz2 On 10/19/2016 04:08 AM, John Baldwin wrote: > On Wednesday, October 19, 2016 01:09:53 AM Pedro Alves wrote: >> If I run autoheader on the gdb/ dir, I see this spurious >> change come out: >> >> 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. OK, thanks. It's not a big deal. Was just wondering whether the issue was on my side. Since Yao confirms, it doesn't look like it. If when you regen on your side, you still see it like you originally had it, I wonder whether this is a sorting bug in autoheader or one of the utilities it might spawn (perl, shell, etc.?) somewhere. It seems like the HAVE_FOO #undef/#define's in config.in are alphabetically sorted. If I regen, it's fixing the sort. Seems like these macros are the longest named ones in the file, that may be related. Anyway, I'll push it in in a sec. Thanks, Pedro Alves