From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2HVcGYGKYmNyNxMAWB0awg (envelope-from ) for ; Wed, 02 Nov 2022 11:19:29 -0400 Received: by simark.ca (Postfix, from userid 112) id 594E01E124; Wed, 2 Nov 2022 11:19: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=LrG6cTd8; 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=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 067EE1E0D3 for ; Wed, 2 Nov 2022 11:19:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 492573856DD5 for ; Wed, 2 Nov 2022 15:19:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 492573856DD5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667402368; bh=iTqxJqxKN1DxpKDy2X1ZJF7okUk02h79GMIJCev0LMg=; 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=LrG6cTd8u6sO1f1dYA5gUqC+NdVRhR54Q5R/jijuJydWS245ITkdsq839a1mNlwNt wedjRsqbKJlYavmM7tKzkzndHxhHJ4Z8oaeKvC7NoqR1CVMDTwk1oA7Hbqkf7AH9S/ aJtRIy3WZLvlOikS9j0hF70nSDRD5QPmL3dfZXQU= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id D37E83857030 for ; Wed, 2 Nov 2022 15:19:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D37E83857030 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 1oqFW7-0004i7-Qu; Wed, 02 Nov 2022 11:18:59 -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 1oqFW6-0003k3-2E; Wed, 02 Nov 2022 11:18:59 -0400 Date: Wed, 02 Nov 2022 17:18:44 +0200 Message-Id: <83h6zh9ygb.fsf@gnu.org> To: i.nixman@autistici.org In-Reply-To: (i.nixman@autistici.org) Subject: Re: _WIN32_WINNT redefined? References: <6485dbfe07e21a1c451b17d3fda5b3d9@autistici.org> <41193fbdb742b1c2d4d7b4ab06561822@autistici.org> <8335b1bjv2.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" > Date: Wed, 02 Nov 2022 14:13:13 +0000 > From: i.nixman@autistici.org > > the root of the issue: GDB wan't build using MinGW-W64 toolchain uses > this patch: > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054895.html > (for short, the patch provides the ability to libstdc++ to enable the > support for std-threads and so on but without the need to use > libwinpthreads: > https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/) > > next, as I wrote earlier, I have faced with a trouble I can't build GDB > using that path: > ``` > 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; } > | ^~~~~~~~~~~~~~~~ > ``` > > because the patch requires the _WIN32_WINNT will be set to 0x0600 or > greater. Then the stuff in common-defs.h should be augmented to define _WIN32_WINNT to the value 0x0600 or greater, if it isn't already high enough, but only if the patch for gthreads is being used. How exactly to write the cpp conditional for that, I don't know, but hopefully you will be able to figure that out. Or maybe you should do that in gdbsupport/thread-pool.cc instead. Whatever is easier. One thing is certain: GDB builds on Windows that don't use the gthread patch should not be broken by increasing the minimum value of _WIN32_WINNT with which GDB can be built on Windows. > as solution I see two ways: > 1) to remove that PP block completely, because as I wrote earlier - no > one in the GDB sources refers to it. > 2) to hide that PP block so that it cannot "infect" other code by by > getting into public headers. I think the right solution is: 3) amend the cpp block to define _WIN32_WINNT to 0x0600 if the threads patch is being used.