From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id C58BF3892454 for ; Sat, 12 Sep 2020 17:36:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C58BF3892454 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:40076) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kH9Ra-0008Nb-1a; Sat, 12 Sep 2020 13:36:10 -0400 Received: from [176.228.60.248] (port=2924 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kH9RZ-0005nf-HM; Sat, 12 Sep 2020 13:36:09 -0400 Date: Sat, 12 Sep 2020 20:36:09 +0300 Message-Id: <83lfhedhiu.fsf@gnu.org> From: Eli Zaretskii To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20200912163346.GB5423@adacore.com> (message from Joel Brobecker on Sat, 12 Sep 2020 09:33:46 -0700) Subject: Re: Problem building today's snapshot with MinGW References: <83tuw5ir09.fsf@gnu.org> <20200912163346.GB5423@adacore.com> X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, 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 17:36:11 -0000 > Date: Sat, 12 Sep 2020 09:33:46 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > 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. It's indeed a workaround, because I actually believe the code is wrong, and the entire part that redefines _WIN32_WINNT should be dropped, as the rest of the code is well equipped to handle any reasonable value of _WIN32_WINNT. I used the workaround because I'm still not 100% sure I'm not missing something, which could explain why the Gnulib folks have this code there. It is also the reason why I didn't post the patch to the Gnulib list, but instead asked them why that part of the code was at all necessary.