From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MM9YINtnYmNVLBMAWB0awg (envelope-from ) for ; Wed, 02 Nov 2022 08:51:39 -0400 Received: by simark.ca (Postfix, from userid 112) id 7761C1E124; Wed, 2 Nov 2022 08:51:39 -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=IkAkT4O0; 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 1DF4B1E0CB for ; Wed, 2 Nov 2022 08:51:39 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7F9593858419 for ; Wed, 2 Nov 2022 12:51:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F9593858419 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667393498; bh=sqA4wekpDEDgiNxvIfPWLv5eWsKEqKumB20BW4SNFR8=; 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=IkAkT4O0cnoUXdlvMBTD7wsNR1gTSQ5lfc4RAfa5196tKdNYOKWPaeS366JMIOTQk ajRxKsw3NQV1jCkljRNVl2aGeDc82TMQEjERElZYT5nYOEuW/nNHFBaxc7/1kl2Fit hsy0tWx/gOARdR2buWMxr9AvZjl3r5IcpqT+odqs= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 56FB03858C50 for ; Wed, 2 Nov 2022 12:51:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56FB03858C50 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 1oqDD2-0005oh-Ny; Wed, 02 Nov 2022 08:51:08 -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 1oqDD2-0003G5-5i; Wed, 02 Nov 2022 08:51:08 -0400 Date: Wed, 02 Nov 2022 14:50:57 +0200 Message-Id: <8335b1bjv2.fsf@gnu.org> To: i.nixman@autistici.org In-Reply-To: (message from niXman via Gdb on Wed, 02 Nov 2022 09:46:20 +0000) Subject: Re: _WIN32_WINNT redefined? References: <6485dbfe07e21a1c451b17d3fda5b3d9@autistici.org> <41193fbdb742b1c2d4d7b4ab06561822@autistici.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" > Date: Wed, 02 Nov 2022 09:46:20 +0000 > From: niXman via Gdb > > On 2022-11-02 08:44, niXman via Gdb wrote: > > On 2022-11-02 08:21, niXman via Gdb wrote: > > ok, I did a little research. > > the `_WIN32_WINNT` is defined in `gdbsupport/common-defs.h` only, but > referenced in `gnulib/import/gettimeofdeay.c` and > `gnulib/import/stat-w32.c` only, but not directly because those files > include `windows,h` and `sdkdkver.h`. thus that `_WIN32_WINNT` define is > never used! No, _WIN32_WINNT is referenced in a lot of w32api header files, which use it to decide whether to expose function prototypes, data type declarations, macros, etc. In effect, the value of _WIN32_WINNT determines the oldest version of MS-Windows which the program needs to support, by hiding APIs that are not available on later versions -- this ensures the program doesn't use those later APIs unintentionally. > so I think the best way is to remove that define completely. No, that's wrong, because if you remove that, you will basically force everyone who builds GDB for Windows to use the default value of _WIN32_WINNT defined by the w32api headers. And that default is not necessarily what we want. > ideas? Find out why the current definition causes trouble in your build, then we could discuss the correct solution that works for everyone. In the original report you said: > In file included from > mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/mutex:45, > from > ../src/gdb-11.2/gdbsupport/../gdbsupport/thread-pool.h:27, > from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24: > mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/bits/std_mutex.h:163:5: > error: '__gthread_cond_t' does not name a type; did you mean > '__gthread_once_t'? > 163 | __gthread_cond_t* native_handle() noexcept { return > &_M_cond; } > | ^~~~~~~~~~~~~~~~ > ``` > > the problem is a consequence of the fact that `_WIN32_WINNT` is > redefined somewhere to another value that is less than necessary. > but when I pass `-D_WIN32_WINNT=0x0601` for CFLAGS/CXXFLAGS - the > trouble is gone. This doesn't explain why -D_WIN32_WINNT=0x0601 solves the problem. Can you explain that in enough detail, and point to the relevant parts of the headers? In addition, you point to this place in common-defs.h: /* We don't support Windows versions before XP, so we define _WIN32_WINNT correspondingly to ensure the Windows API headers expose the required symbols. */ #if defined (__MINGW32__) || defined (__CYGWIN__) # ifdef _WIN32_WINNT # if _WIN32_WINNT < 0x0501 # undef _WIN32_WINNT # define _WIN32_WINNT 0x0501 # endif # else # define _WIN32_WINNT 0x0501 # endif #endif /* __MINGW32__ || __CYGWIN__ */ This defines _WIN32_WINNT only if it wasn't already defined, or if it was defined to a value smaller than 0x0501. So why isn't _WIN32_WINNT defined in your w32api headers? It should be defined to some default value, which was determined when the w32api headers were produced, and I'm guessing that this default value should be 0x0601, in which case the above preprocessor stuff should not redefine it.