在 2020/12/26 上午4:41, Martin Storsjö 写道:
>
> Maybe they don't do that right in any places right now, but despite that, I
> believe there's a value
> in distinguishing between __MSVCRT_VERSION__ 0xA00 (aka msvcr100.dll) and a
> modern msvcrt.dll on
> Windows 7, so something like "__MSVCRT_VERSION_
在 2021/1/14 上午5:14, Martin Storsjö 写道:
>
> --- a/mingw-w64-headers/crt/_mingw.h.in
> +++ b/mingw-w64-headers/crt/_mingw.h.in
> (...)
> + __asm__ __volatile__("unimplemented");
I suggest an `#error` here so the error could be caught earlier.
> --- a/mingw-w64-headers/include/winnt.h
> +++ b/min
On Wed, 13 Jan 2021, Martin Storsjö wrote:
> The pragmatic path forward in that case, I think, would to add a configure
> option to mingw-w64-crt for optionally enabling the __cxa_thread_atexit
> function. So if that's omitted from mingw-w64-crt, a new build of libstdc++
> would include their vers
On Wed, 13 Jan 2021, Martin Storsjö wrote:
> I haven't spent a lot of more time on it unfortunately, but I think my
> concluding thoughts were that it seems hard to get to work properly in this
> particular setup: As long as there's callbacks for both emutls for the
> allocations, and for __cxa_th
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/_mingw.h.in | 8
mingw-w64-headers/include/winnt.h | 6 ++
2 files changed, 14 insertions(+)
diff --git a/mingw-w64-headers/crt/_mingw.h.in
b/mingw-w64-headers/crt/_mingw.h.in
index 01eff66fa..25513d7da 100644
--- a/mingw-w64-
On Fri, 18 Dec 2020, Jeremy Drake via Mingw-w64-public wrote:
Have there been any further ideas on this? I am concerned the current
state of affairs, accessing freed memory during tls destruction of objects
in the .exe module, could cause crashes in objects more complicated than
simple logging
As we are talking about ARM, would you please also add YieldProcessor
for aarch64 **and** armv7? Previously, for testing, I compiled a dummy
file with MSVC (cl.exe /FAs), copied the assembly into __asm() and
compiled a project with llvm-mingw.
___
Mingw
On Tue, 12 Jan 2021, Jeremy Drake via Mingw-w64-public wrote:
I was trying to build libuv on aarch64-w64-mingw32, and ran into an issue
that MemoryBarrier was undefined, and tracing through the headers it does
in fact seem to only be defined for i386/x86_64/ia64. Is it supposed to
be defined on
On Tue, 12 Jan 2021, Liu Hao wrote:
While we’re at it, how could we reflect the target CRT (MSVCRT, UCRT, or one
of the version-specific RTs)?
Ideally they should be denoted by distinct triplets. For example, on Linux
`*-*-linux` and
`*-*-linux-gnu` are triplets for Glibc, while targets that
在 2021-01-13 10:54, Clinton Reddekop 写道:
Hello,
I have mingw-w64 compiler tools version 8.1.0, downloaded here:
https://sourceforge.net/projects/mingw-w64/files/Toolchains targetting
Win32/Personal Builds/mingw-builds/installer/mingw-w64-install.exe/download
niXman [1] used to maintain those
On 11.01.2021 18:37, Biswapriyo Nath wrote:
Hmmm why aren't those IDLs imported from Wine?
1. Huge confusion. IExtractIcon is in -- shlobj_core.h in WinSDK,
shlobjidl.idl in wine, shlobj.h in mingw-w64.
2. Files differ largely between mingw-w64 and wine.
We still may import them, it's just mo
11 matches
Mail list logo
