From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZuZoNEFwYmMZLxMAWB0awg (envelope-from ) for ; Wed, 02 Nov 2022 09:27:29 -0400 Received: by simark.ca (Postfix, from userid 112) id C88251E124; Wed, 2 Nov 2022 09:27:29 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=UXeYq1pD; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 78C241E0CB for ; Wed, 2 Nov 2022 09:27:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A893D3858426 for ; Wed, 2 Nov 2022 13:27:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A893D3858426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667395648; bh=lbIzMyQGBcW2bhR37Z6i6mJBBnAtcnj2gplIAOyALmc=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=UXeYq1pD2ZS6wcxVaG+5isPNOuUHhUfzyeb3d9cBOthwFLfoea9kU53veyUY6GnsX xU4A5bs99uJGPrTE9Qc5H8Wt5L8rxh53BN0Z9ix/uNHzVYX2k82w3jWxo4WOf6TVNH Ny4jJHKu64Rl1y3HGR8ru/+wgYuuz2KMFQrXcS30= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4B2203858D3C for ; Wed, 2 Nov 2022 13:27:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B2203858D3C Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqDlk-0008Kj-Ox; Wed, 02 Nov 2022 09:27:00 -0400 Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqDlk-0004nD-53; Wed, 02 Nov 2022 09:27:00 -0400 Date: Wed, 02 Nov 2022 15:26:49 +0200 Message-Id: <83sfj1a3mu.fsf@gnu.org> To: noloader@gmail.com In-Reply-To: (message from Jeffrey Walton on Wed, 2 Nov 2022 09:10:21 -0400) Subject: Re: _WIN32_WINNT redefined? References: <6485dbfe07e21a1c451b17d3fda5b3d9@autistici.org> <41193fbdb742b1c2d4d7b4ab06561822@autistici.org> <6acd12904c2bedb0a96162354d1ee8dd@autistici.org> <83zgd9a4w7.fsf@gnu.org> X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb Reply-To: Eli Zaretskii Cc: gdb@sourceware.org Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" > From: Jeffrey Walton > Date: Wed, 2 Nov 2022 09:10:21 -0400 > Cc: i.nixman@autistici.org, gdb@sourceware.org > > > > right, with commented out the entire PP block the build was successful! > > > > This is the wrong solution, IMO. > > Here's what Microsoft has to say about it: > https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt > " > > To modify the macros, in a header file (for example, in targetver.h, > which is included by some project templates that target Windows), > add the following lines. > > #define WINVER 0x0A00 > #define _WIN32_WINNT 0x0A00 > > If I am reading that correctly, there should be a common header file > which defines WINVER and _WIN32_WINNT. In my old MFC days, we would > set it in a file like . In a non-MFC project, we would set > it under the Visual Studio preprocessor macros, which is just > CPPFLAGS. I believe we use common-defs.h as that common header. > Maybe there needs to be a configure option to set the values. What for? I see no reason to expose this complexity to people who configure GDB. The underlying problem here is that one of the two flavors of MinGW has its headers (and _WIN32_WINNT in particular) set for Widows 9X, and GDB no longer supports those old versions. So we force the w32api headers of that MinGW flavor to expose the parts that are supported on Windows XP and later. If the w32api headers are set for a higher value of _WIN32_WINNT (as the other MinGW flavor already does), then the offending part of common-defs.h should be a no-op. Why this didn't work for the OP is unclear. Until it is clear, IMO we are not ready to have a rational discussion of the solutions for the issue.