From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id 001F438708FA for ; Sat, 12 Sep 2020 16:33:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 001F438708FA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id CD62411760D; Sat, 12 Sep 2020 12:33:48 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NGuisdwd5Pmb; Sat, 12 Sep 2020 12:33:48 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9FA181175B7; Sat, 12 Sep 2020 12:33:48 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E51CD83421; Sat, 12 Sep 2020 09:33:46 -0700 (PDT) Date: Sat, 12 Sep 2020 09:33:46 -0700 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: Problem building today's snapshot with MinGW Message-ID: <20200912163346.GB5423@adacore.com> References: <83tuw5ir09.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83tuw5ir09.fsf@gnu.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2020 16:33:50 -0000 > At Joel's request, I've built today's snapshot of the GDB master > branch using mingw.org's MinGW, and found a problem when running the > produced gdb.exe on versions of Windows older than 8.0 (in my case it > was XP). The details are described in my report to the Gnulib folks: > > https://lists.gnu.org/archive/html/bug-gnulib/2020-09/index.html FTR, the direct link to the actual email is: https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00027.html > The provisional patch I used to solve this problem is this: I created the following gdb/build PR: https://sourceware.org/bugzilla/show_bug.cgi?id=26607 > --- gnulib/import/stat-w32.c~ 2020-09-10 04:47:11.000000000 +0300 > +++ gnulib/import/stat-w32.c 2020-09-10 16:05:46.789125000 +0300 > @@ -20,10 +20,14 @@ > > #if defined _WIN32 && ! defined __CYGWIN__ > > +#if _GL_WINDOWS_STAT_INODES == 2 > /* Ensure that defines FILE_ID_INFO. */ > -#if !defined _WIN32_WINNT || (_WIN32_WINNT < _WIN32_WINNT_WIN8) > -# undef _WIN32_WINNT > -# define _WIN32_WINNT _WIN32_WINNT_WIN8 > +# if !defined _WIN32_WINNT || (_WIN32_WINNT < _WIN32_WINNT_WIN8) > +# undef _WIN32_WINNT > +# define _WIN32_WINNT _WIN32_WINNT_WIN8 > +# endif > +#elif !defined VOLUME_NAME_NONE > +# define VOLUME_NAME_NONE 0x4 > #endif >From what I understood of the analysis, gnulib is doing something pretty questionable (forcing _WIN32_WINNT to the wrong value) in order to get FILE_ID_INFO being defined; and looking at your patch and the explanation you gave in the report to gnulib, you found that the APIs in question are only needed if _GL_WINDOWS_STAT_INODES and so fixed this by only enabling the redefined based on this variable. So for me, this is more of a workaround than an actual fix. Between this and the fact that all versions of Windows older than 8.1 are no longer supported by Microsoft, I can anticipate some push back from the gnulib community. The question we then want to ask ourselves, is whether we want to continue supporting older versions of Windows. I'm personally not opposed, but it has to be at a reasonable cost, meaning that it can only be acceptable if changes made to support those versions don't increase the maintenance burden. Unfortunately, I don't think the patch above meets those requirements. I'm not opposed to having some kind of fix to be discussed in the upcoming gdb-10-branch, though, because there we know the extra burden would only last as long as the branch itself. Thoughts? -- Joel