From: i.nixman@autistici.org
To: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
Subject: Re: _WIN32_WINNT redefined?
Date: Wed, 02 Nov 2022 14:13:13 +0000 [thread overview]
Message-ID: <b9583b31c9c4061bf750b1331dc475ee@autistici.org> (raw)
In-Reply-To: <8335b1bjv2.fsf@gnu.org>
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!
next prev parent reply other threads:[~2022-11-02 14:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 8:14 i.nixman
2022-11-02 8:21 ` i.nixman
2022-11-02 8:44 ` i.nixman
2022-11-02 9:46 ` i.nixman
2022-11-02 10:15 ` i.nixman
2022-11-02 12:59 ` Eli Zaretskii
2022-11-02 13:10 ` Jeffrey Walton
2022-11-02 13:26 ` Eli Zaretskii
2022-11-02 12:50 ` Eli Zaretskii
2022-11-02 14:13 ` i.nixman [this message]
2022-11-02 15:18 ` Eli Zaretskii
2022-11-02 15:51 ` i.nixman
2022-11-02 16:02 ` i.nixman
2022-11-02 16:51 ` Eli Zaretskii
2022-11-02 17:20 ` i.nixman
2022-11-02 18:13 ` Eli Zaretskii
2022-11-02 12:55 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9583b31c9c4061bf750b1331dc475ee@autistici.org \
--to=i.nixman@autistici.org \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).