From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ot81Dll7YmOTMhMAWB0awg (envelope-from ) for ; Wed, 02 Nov 2022 10:14:49 -0400 Received: by simark.ca (Postfix, from userid 112) id 2B9671E124; Wed, 2 Nov 2022 10:14:49 -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=T6HZpSPw; 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 2EACD1E0CB for ; Wed, 2 Nov 2022 10:14:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A01F6385701D for ; Wed, 2 Nov 2022 14:14:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A01F6385701D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667398486; bh=SVczos8/cgbWTGXxIvTZIB5m89SsiNhnFGW1qETab1c=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=T6HZpSPw/KamMh+hFpWen6bDHkMSJFaq24HjSFHBtKqf2sEwOOfmeabwJnuy98eNf mQ6GjVwGrwLIE0bJwOF7C+B0isd8JhGh7qbHotqgKzqZ767nv5cmXJZInTCzfNT2e+ WR9CYsgJTFxbk+l8uho16JrDhHG5lwcKsTQYSyyM= Received: from latitanza.investici.org (latitanza.investici.org [82.94.249.234]) by sourceware.org (Postfix) with ESMTPS id 0BEA13858C66 for ; Wed, 2 Nov 2022 14:13:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0BEA13858C66 Received: from 1.mail-backend.investici.org (unknown [10.0.0.11]) by latitanza.investici.org (Postfix) with ESMTP id 4N2TPk1YbvzGp3R; Wed, 2 Nov 2022 14:13:14 +0000 (UTC) Received: from 1.webmail.investici.org (localhost [127.0.0.1]) (Authenticated sender: i.nixman@autistici.org) by 1.mail-backend.investici.org (Postfix) with ESMTPA id 4N2TPk0JnGz5t7d; Wed, 2 Nov 2022 14:13:14 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 02 Nov 2022 14:13:13 +0000 To: Eli Zaretskii , gdb@sourceware.org Subject: Re: _WIN32_WINNT redefined? In-Reply-To: <8335b1bjv2.fsf@gnu.org> References: <6485dbfe07e21a1c451b17d3fda5b3d9@autistici.org> <41193fbdb742b1c2d4d7b4ab06561822@autistici.org> <8335b1bjv2.fsf@gnu.org> User-Agent: Roundcube Webmail Message-ID: X-Sender: i.nixman@autistici.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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: niXman via Gdb Reply-To: i.nixman@autistici.org Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-11-02 12:50, Eli Zaretskii wrote: Hello Eli! I will try to explain step by step. 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. next, GDB's building process trying to build `gdbsupport/thread-pool.cc` which includes `common-defs.h` first. then, `gdbsupport/thread-pool.cc` includes `gdbsupport/thread-pool.h` which includes other standard headers like condition_variable/mutex/thread, etc. at this point the inclusion chain looks like this: `mutex`[1] -> `bits/std_mutex.h`[2] -> `bits/gthr.h`[3] -> `gthr-default.h`[4] [1] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/mutex;h=b310c15687d323c1750f717e630fbe0666515139;hb=HEAD [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/std_mutex.h;h=b22e0e12793700291c65c1695313dbeae4561da2;hb=HEAD [3] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/gthr.h;h=7943c94f6d16b7aed4269aa08db746ae131430b1;hb=HEAD (note for this link: in reality that file located inside gcc sources as `libgcc/gthr.h`, but on target toolchain it is `bits/gthr.h` without any changes) [4] https://pastebin.com/LbE0qbwu (note for this link: I paste that file on pastebin because I want to show you how looks that file after applying the patch) now look at the 4 link at line 65: `#if _WIN32_WINNT >= 0x0600` that is, in this case the definition from within the GDB sources "infects" the GCC sources. do you agree that this should not be the case? well, back to the root. please look at `gdbsupport/common-defs.h`: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD you may not believe me, but none of the inclusions above that preprocessor block I'm talking about include neither `windows.h` nor `winver.h` nothing that could tell to that preprocessor block the value of `_WIN32_WINNT` :) thus, it turns out that that preprocessor block of code does not check and does not correct the value of `_WIN32_WINNT` but simply always imposes its value. 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. best!