,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 15.06.2025 19:36, Jeremy Drake via Mingw-w64-public wrote:
I just tried to build llvm-mingw on Cygwin, as part of testing builds of
llvm/clang/lld on Cygwin, and got a new error building widl:
In file included from /usr/include/limits.h:13,
from /usr/lib/gcc/x86_64-pc
I just tried to build llvm-mingw on Cygwin, as part of testing builds of
llvm/clang/lld on Cygwin, and got a new error building widl:
In file included from /usr/include/limits.h:13,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/limits.h:203,
from /usr/lib/gcc
Jeremy Drake
Jøger Hansegård
Kirill Makurin
Lasse Collin
Le Philousophe
LIU Hao
Marc-André Lureau
Martin Storsjö
Nikolay Sivov
Pali Rohár
Rafael Kitover
Steve Lhomme
TheShermanTanker
Yang Kun
And here are the downloads:
https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw
preinstalled development resources. The process
can be made automatic.
FWIW, it shouldn't be too hard to write a tool that merges .def files
from multiple architectures into a single .def.in, adding conditional
macros where needed.
Thanks,
Jacek
______
On 25.05.2025 18:10, Martin Storsjö wrote:
On Sun, 25 May 2025, Jacek Caban via Mingw-w64-public wrote:
This reverts commit 8c2c00ef898f36d51613b45c2cab4f4448d35f0b.
These functions can unwind to the current frame, in which case they
effectively return.
Therefore, they should not be marked
are you suggesting we
duplicate all the .def files for a fifth time, rather than just
adjusting a few as we did?
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
'*' in the commit message is a typo, I will remove it.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
://gitlab.winehq.org/mono/wine-mono/-/merge_requests/30.
---
mingw-w64-crt/misc/arm64ec/longjmp.c | 1 +
mingw-w64-headers/include/winnt.h| 10 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/mingw-w64-crt/misc/arm64ec/longjmp.c
b/mingw-w64-crt/misc/arm64ec/longjmp.c
index
On 23.05.2025 19:12, Martin Storsjö wrote:
On Fri, 23 May 2025, Jacek Caban via Mingw-w64-public wrote:
And use it for exports not available on ARM64EC.
---
mingw-w64-crt/def-include/func.def.in | 9 ++---
.../lib-common/api-ms-win-crt-math-l1-1-0.def.in | 2
---
mingw-w64-crt/Makefile.am | 5 +
1 file changed, 5 insertions(+)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index e5ca242db..e08173d9f 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -520,6 +520,10 @@ src_ucrtbasearm32
And use it for exports not available on ARM64EC.
---
mingw-w64-crt/def-include/func.def.in| 9 ++---
.../lib-common/api-ms-win-crt-math-l1-1-0.def.in | 2 +-
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
mingw-w64-crt/lib-common/ntdll.def.in
On 18.05.2025 21:08, Martin Storsjö wrote:
On Sat, 17 May 2025, Jacek Caban via Mingw-w64-public wrote:
---
mingw-w64-crt/def-include/func.def.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-crt/def-include/func.def.in
b/mingw-w64-crt/def-include/func.def.in
index
On 17.05.2025 12:15, LIU Hao wrote:
Private exports are commented out.
Signed-off-by: LIU Hao
---
mingw-w64-crt/lib-common/oleacc.def | 15 ++-
mingw-w64-crt/lib32/oleacc.def | 15 ++-
2 files changed, 20 insertions(+), 10 deletions(-)
Looks good to me
---
mingw-w64-crt/def-include/func.def.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-crt/def-include/func.def.in
b/mingw-w64-crt/def-include/func.def.in
index 1d542a1f4..f180b9ce7 100644
--- a/mingw-w64-crt/def-include/func.def.in
+++ b/mingw-w64-crt/def-include/func.def.in
---
mingw-w64-crt/lib-common/ntdll.def.in | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-crt/lib-common/ntdll.def.in
b/mingw-w64-crt/lib-common/ntdll.def.in
index ee002c868..efa6145b6 100644
--- a/mingw-w64-crt/lib-common/ntdll.def.in
+++ b/mingw-w64-crt
Ah ok, so we just have to wait for it to show up in MSYS?
Sent with Proton Mail secure email.
On Thursday, April 24th, 2025 at 1:46 AM, Biswapriyo Nath
wrote:
> Previous patch https://sourceforge.net/p/mingw-w64/mailman/message/59175
Ah ok. I didn't know. I did attach it as a .patch file.
It should be a .txt now
Sent with Proton Mail secure email.
On Tuesday, April 22nd, 2025 at 5:14 AM, JonY via Mingw-w64-public
wrote:
> On 4/22/25 10:06 AM, Zach Bacon wrote:
>
> > I think you forgot to attach the
On 4/22/25 10:06 AM, Zach Bacon wrote:
I think you forgot to attach the patch
On Tue, Apr 22, 2025, 5:28 a.m. Hernan Martinez via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net> wrote:
The exported symbols are the same as x64
Please add the patch attachment as .txt, SF ha
The exported symbols are the same as x64
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On Fri, 18 Apr 2025, Martin Storsjö wrote:
> On Tue, 15 Apr 2025, Jeremy Drake via Mingw-w64-public wrote:
>
> > Unfortunately, the test-llvm-mingw and test-libcxx jobs fail for arm64.
> > I'm not clear on why. The test-ffmpeg jobs work, though
>
> FWIW, the tests t
Unfortunately, the test-llvm-mingw and test-libcxx jobs fail for arm64.
I'm not clear on why. The test-ffmpeg jobs work, though
---
.github/workflows/build.yml | 40 +++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/.github/workflows/buil
On Tue, 1 Apr 2025, Jacek Caban wrote:
> diff --git a/mingw-w64-crt/include/internal.h
> b/mingw-w64-crt/include/internal.h
> index 84d52c991..b30ae0e5f 100644
> --- a/mingw-w64-crt/include/internal.h
> +++ b/mingw-w64-crt/include/internal.h
> @@ -287,6 +287,14 @@ static i
n that the change is a workaround for
`libgcc`. I can add condition that this workaround will be applied only when
MinGW is being built with GCC and only when `libgcc` is available. How would
you detect the scenario when `mingw-w64-crt` is being built for the future use
with `mingw-w64-crt/w
HI all,
How soon after GCC 15.1.0 is released will there be packages for it? I am
predominately interested in
The CodeView debugging information it will generate so I can use binutils to
generate PDB files.
Thanks,
Tom
___
Mingw-w64-public
build that adds
`-mno-outline-atomics` flag to build of `mingw-w64-crt` and
`mingw-w64-libraries/winpthreads`. Note that the flag is required for both
libraries.
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-libraries/winpthreads/Makefile.am | 1 +
mingw-w64-libraries/w
solution.
More details on the root cause of the outline atomics issue can be found at
https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/issues/208
---
mingw-w64-libraries/winpthreads/Makefile.am | 6 +-
mingw-w64-libraries/winpthreads/Makefile.in | 26
mingw-w64-libraries
The _S_IFBLK macro, used to identify block special files in file systems, is
being updated from 0x3000 to 0x6000. This change aligns mingw-w64 with the more
commonly used value across Unix-like systems and other C libraries.
The old value of 0x3000 may have caused compatibility issues when
On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> Interesting, I could try that but probably not until Monday.
I found some time this afternoon to clean up a bit:
https://github.com/jeremyd2019/binutils-gdb/compare/master...delayimp-didat-section
https://github.com/jeremyd2
On Sat, 8 Mar 2025, LIU Hao wrote:
> 在 2025-3-8 10:23, Jeremy Drake via Mingw-w64-public 写道:
> > > This patch unfortunately does a few different things at this point:
> > > * moves delay load directory table into .didat$2 section, and puts this
> > > into .idata
ta`), at the moment
> the difference can't be negative. However I suggest we change this to
Woah, no, the ppfnIATEntry must be in the delay IAT for this DLL,
therefore it must be greater than the base address of the delay IAT for
this DLL. If not, something is really wrong wit
On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
>
> > On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> >
> > > That bug was avoided, due to the fact that the code that tries to
&
On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
>
> > That bug was avoided, due to the fact that the code that tries to
> > garbage-collect unused stubs only looks at .idata sections, and delayloads
>
On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> That bug was avoided, due to the fact that the code that tries to
> garbage-collect unused stubs only looks at .idata sections, and delayloads
> are now in .didat sections.
>
> However, this patch is probably overkill.
On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> On Sat, 8 Mar 2025, LIU Hao wrote:
>
> > Please try this patch for binutils.
>
> Will do. Could you also take a look at
> https://sourceware.org/bugzilla/show_bug.cgi?id=14339 ? It should be
> 'adjacent
renced' so they're emitted.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On Fri, 7 Mar 2025, LIU Hao wrote:
> Ahh right. I have found my issue now. I was using a patched binutils like in
> Wine [1]. It produced delay-import data which somehow worked if passed to
> `ResolveDelayLoadedAPI()`, but the mingw-w64 implementation didn't like it. It
> was
On Thu, 6 Mar 2025, Jeremy Drake via Mingw-w64-public wrote:
> On Thu, 6 Mar 2025, Jacek Caban wrote:
>
> > Relying on __delayLoadHelper2 behavior specific to mingw-w64 comes with
> > drawbacks. As I mentioned earlier, an application can forward the call
> > to ResolveDe
On Thu, 6 Mar 2025, Jacek Caban wrote:
> Relying on __delayLoadHelper2 behavior specific to mingw-w64 comes with
> drawbacks. As I mentioned earlier, an application can forward the call
> to ResolveDelayLoadedAPI, which will bypass this change and fail to
> work, while it previously
clear message that users can understand
without needing to dive into mingw-w64 specifics.
I’ve attached a possible solution on the LLD side. In its current
form, it would warn on recent CFGuard-enabled mingw-w64 due to the
missing @feat.00 flag, but it's just an example of a pote
unaffected.
---
v3: Use CFGSYM for checker function pointers too, drop @feat.00 changes.y
mingw-w64-crt/Makefile.am | 8 ++
mingw-w64-crt/configure.ac| 4 +--
.../mingw_cfguard_loadcfg.S => crt/loadcfg.S} | 28 +++
3 files changed,
ds,
/Pete
On 2025.03.04 03:37, LIU Hao wrote:
在 2025-03-04 01:14, Pete Batard via Mingw-w64-public 写道:
Considering that the current approach to fighting DLL side-loading
vulnerabilities for MinGW generated executables is to manually run
them through something like procmon, to see if they attempt to
Hi,
By default, the gcc generated PE binaries do not appear to have
directory entry #11, a.k.a 'Load Configuration', whereas MSVC generated
ones do:
$ objdump -x mingw/rufus.exe | grep "Load Configuration"
Entry a Load Configuration Directory
unaffected.
---
mingw-w64-crt/Makefile.am | 8 ++---
mingw-w64-crt/configure.ac| 4 +--
.../mingw_cfguard_loadcfg.S => crt/loadcfg.S} | 30 +--
3 files changed, 24 insertions(+), 18 deletions(-)
rename mingw-w64-crt/{cfgu
, this means load config will always be present in output
images when using
LLD. Since ld.bfd does not support load config, it remains unaffected.
---
mingw-w64-crt/Makefile.am | 7
+--
mingw-w64-crt/configure.ac | 4
It seems to me that
LLVM/Clang does not implement this behaviour, even in MSVC mode. We
might need to request this to be implemented upstream.
Regardless, mingw-w64 will need to support versions of LLVM without this
preprocessor. Also, I'm not sure if this preprocessor would even apply
. Since ld.bfd does not support load config, it remains unaffected.
---
mingw-w64-crt/Makefile.am | 7 +--
mingw-w64-crt/configure.ac | 4 +---
.../{cfguard/mingw_cfguard_loadcfg.S => crt/loadcfg.S} | 0
3 files changed
Thank you, Liu Hao. There is one more static assert to fix (the first one).
Otherwise, it looks great!
Best regards,
Jøger Hansegård
From: LIU Hao
Sent: Saturday, March 1, 2025 7:21:01 AM
To: mingw-w64-public@lists.sourceforge.net
; Zach Bacon
Cc: Jøger
comparison operators for Microsoft::WRL::ComPtr
The current MinGW implementation of Microsoft::WRL::ComPtr does not have
comparison operators. Attempting to compare two ComPtr instances will
implicitly convert the ComPtr to bool, and comparison is performed
against the resulting two bool values. This
The current MinGW implementation of Microsoft::WRL::ComPtr does not have
comparison operators. Attempting to compare two ComPtr instances will
implicitly convert the ComPtr to bool, and comparison is performed
against the resulting two bool values. This means that any two non-null
ComPtr instances
the exception mask bits.
Code on line 38-41 does the correct operation to the x87 status bits.
Signed-off-by: LIU Hao
---
mingw-w64-crt/misc/fesetexceptflag.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
ping
Patch looks OK to me, thanks
D_STANDARD_NAMES at all, or something similar.
[1]
https://learn.microsoft.com/en-us/cpp/c-runtime-library/secure-template-overloads
Sincerely, Seth McDonald.
PGP Fingerprint
82B9 620E 53D0 A1AE 2D69 6111 C267 B002 0A90 0289
signature.asc
Description: OpenPGP digital signature
_____
bug report 999. See [3].
[1]:
https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-pathquotespacesa
[2]:
https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-pathquotespacesw
[3]: https://sourceforge.net/p/mingw-w64/bugs/999/
Fixes: 9d937a7f4f76 ("Add
rch64.")
---
Is this OK, or does it need any other preprocessor checks before using
push_macro/pop_macro? I grepped for other usages and it seems like this
is how it's done...
mingw-w64-headers/include/winnt.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-headers/inc
-scoped register variable too).
_______
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
e do a macro push/pop and
undef register? I don't know if the benefits of the register variable
justify the added complexity over the original implementation though.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https
On Fri, 13 Dec 2024, Jacek Caban wrote:
>
> This change is based on Wine's winnt.h implementation. Using a register
> variable for NtCurrentTeb
> allows the compiler to optimize the access more effectively.
> ---
> mingw-w64-headers/include/winnt.h | 5 ++---
> 1 file c
Hi!
I'm wondering whether I can get connected to an upstream developer who is
already contributing to mingw-w64 to add an updated Windows SDK header.
Thanks!
Em Fang
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
long long b = a + (1ULL << 63);
>
> if (((long long) a - (long long) b) >= 0)
> printf("wrong\n");
> else
> printf("right\n");
>
> return 0;
> }
>
> with mingw gcc compiler:
>
> /home/johannes/.zeranoe/mingw
On Thu, 5 Dec 2024, Martin Storsjö wrote:
> When the destructors of the TLS objects are executed via
> mingw-w64-crt's __cxa_thread_atexit, those destructors are executed
> via a TLS callback, after the point when emutls has deallocated
> their storage memory.
> Unfortunatel
ly shouldn't be used, especially if there is no
guarantees against future ABI change, it would cause dependency hell.
As for the warning, I prefer that file magic command be fixed for
libraries rather than working around by file copying.
_______
Mingw-w64-
equently write code of the form `int main (void)` because I
don't care about the command line, but then I wouldn't be passing it any
arguments, unicode or not.
_______
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Mingw-w64 does not provide prebuilt binaries, you should ask your toolchain
provider.
I assume you are using mingw-builds [1] toolchain, so you can try creating an
issue or discussion there.
--
Mateusz
[1] https://github.com/niXman/mingw-builds
Sat, 28 Sep 2024 12:35, Michele Locati
Am Montag, 23. September 2024 um 13:10:23 MESZ hat LIU Hao
Folgendes geschrieben:
> 在 2024-09-23 18:48, Martin Storsjö 写道:
> > Well, as Liu Hao showed, using (void*) casts can get warned about, if we
> > compile it with all
> > available warning flags. But we don'
On Sun, 15 Sep 2024, Pali Rohár wrote:
> Hello, Since recent commit 4cf86b87928c6653612238c1240bf8cb1a697e7e
> ("crt/libsrc: Enable scrnsave code") gcc started throwing new compile
> warnings during compilation of mingw-w64:
>
> libsrc/scrnsave.c: In function ‘WinMain’:
&
Hello :)
I just noticed that libscrnsave does not contain the functions from
scrnsave.h. In the source code, the entire content of scrnsave.c is
unfortunately commented out with #if 0 ... #endif.
Is the Mingw team not interested in providing these functions?
OK, the code in scrnsave.c is
do this is by casting to (void(*)(void)), at
least that's how the gcc docu says this warning should be suppressed:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wcast-function-type
Hannes
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
and currently I am
trying to prepare a toolchain for such older Win Vista (0x0600).
Could you give me some hints if this is possible and what is the reason
of dll icompatibility in the older Win ?
Kind regard,
Piotr Krauze
___
Mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
0x001a164c
Dump of assembler code for function InternetCrackUrlA@16:
0x001a164c <+0>: jmp*0x1ae134
0x001a1652 <+6>: mov$0x1ae134,%eax
0x001a1657 <+11>:jmp0x1a165c <__tailMerge_wininet_delaylib_lib>
End of assembler dump.
__
disass 0x001a164c
Dump of assembler code for function InternetCrackUrlA@16:
0x001a164c <+0>: jmp*0x1ae134
0x001a1652 <+6>: mov$0x1ae134,%eax
0x001a1657 <+11>:jmp0x1a165c <__tailMerge_wininet_delaylib_lib>
End of assembler dump.
___
wrote:
I was looking into delayload stuff a while back, and was pretty
disappointed with how it works in binutils. I suspect some sort of bug in
binutils here. Here are some random thoughts, none of which actually
help.
On Wed, 10 Jul 2024, Pete Batard via Mingw-w64-public wrote:
Hi
I was looking into delayload stuff a while back, and was pretty
disappointed with how it works in binutils. I suspect some sort of bug in
binutils here. Here are some random thoughts, none of which actually
help.
On Wed, 10 Jul 2024, Pete Batard via Mingw-w64-public wrote:
>
Hi,
# Description
This whole issue is better illustrated (and replicated) with the sample
code provided at https://github.com/pbatard/delayload and is the result
of a longstanding issue that I've been battling with when trying to use
DLL delay loading with MinGW in Rufus, per
only apparently relevant change I saw was
the addition of __attribute__((__returns_twice__)) on RtlCaptureContext in
e98e24be8cdb53a1a9e8026b348d33f820a322f6. To test, I commented out the
attribute in /usr/include/w32api/winnt.h and the build succeeded.
I'm not sure if this is an issue in mingw-w6
>You may try 2.36 for example.
Binutils 2.36 segfaults while building the MinGW-w64 CRT, while 2.36.1 builds
the toolchain successfully but shows the previously mentioned relocation error
while compiling hello.c...
Adding these flags:
-Wl,--disable-dynamicbase,--disable-high-entropy
A little update on the faulty cross compiler; the problem is most certainly not
in the MinGW-w64 libraries, as I swapped the libraries between the reference
and faulty toolchains and the results were the same. This leaves the linker...
I tried different Binutils versions and found something
stcall exports (in 4/4 change) did not worked at all.
Just to clarify, the issue was introduced in
c0f06309823c9fcbf37f38272eb3ce4fe042f81a correct? So, not in 12.x?
_______
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.s
Meant to reply here.
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/Nz3uczv--7-9%40tuta.io/#msg58777309
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw
wever rearranging the -l flags and
removing the 2 extra flags to match the faulty toolchain had no effect. This
means both toolchains are using the correct linking command.
This leads me to believe that the problem comes from the MinGW-w64 libraries or
the linker (or both)... How can I debug
v12.0.0 is now released!
Important: UCRT is now the default CRT runtime instead of MSVCRT, check
the mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt document for details.
Both header set and CRT must be configured and built with the same
settings consistently for proper functionality. Switching
I have built a MinGW-w64 cross compiler on a Linux host and it successfully
creates Windows executables, however said executables don't run on Windows nor
Wine...
A simple cross compiled 'hello-world.c' --> 'a.exe' will cause a generic "not a
valid win32 applic
On 5/18/24 08:40, LIU Hao wrote:
在 2024-05-18 13:25, JonY via Mingw-w64-public 写道:
Attached patch OK?
Looks good to me. Thanks.
Thanks, pushed to master branch.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https
Attached patch OK?From dbda83ce39374428f82af7294c876f49d5921483 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 18 May 2024 05:22:34 +
Subject: [PATCH] DFP: fix typos and errors caught by GCC 15
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
m
rnal symbol may conflict with the actual
> import library. Such a case was reported at
> https://github.com/mstorsjo/llvm-mingw/issues/427.
>
> (Practically, the issue there was that some built object files
> defined an external "_time" symbol, i.e. regular "time
Le mercredi 17 avril 2024 à 23:13:18 UTC+2, Martin Storsjö
a écrit :
On Tue, 16 Apr 2024, philippe renon via Mingw-w64-public wrote:
> All this to ask whether that "breaking" change was intentional ?
The change itself was quite intentional, the breakage obviously wasn&#
The Rust test that failed uses the gamma function that depends on sin and log.
So sin and log showed up in the link failure.
I would expect cos to be problematic too.But I can't provide an exhaustive list.
Le mardi 16 avril 2024 à 17:40:34 UTC+2, philippe renon via
Mingw-w64-public a
Note that there are more math functions involved (not just sin).
See the commit that introduced the issue for a full list:
https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1
Le mardi 16 avril 2024 à 16:44:31 UTC+2, Jacek Caban
a écrit :
On
Forgot to mention that this issue affects the MSYS2 build of Rust.See
https://github.com/msys2/MINGW-packages/pull/20397#issuecomment-2050581972
Le mardi 16 avril 2024 à 14:29:22 UTC+2, philippe renon via
Mingw-w64-public a écrit :
One of the Rust unit test fails because of this
One of the Rust unit test fails because of this change :
https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1
The test that fails is externally linking the lgamma function :
https://github.com/rust-lang/rust/blob/c2239bca5b89a8d3573cc0fc0f2fa65c50edb79c/tests/ui
On 1/18/24 16:45, LIU Hao wrote:
在 2024-01-19 00:01, JonY via Mingw-w64-public 写道:
On 1/18/24 12:46, JonY wrote:
Attached patch OK?
Changes unsigned int to unsigned long to match __gdtoa due to gcc
becoming more strict with pointer types.
Attached v2 patch, removed #ifdef and made the type
espite both integer widths are 32bit.
Correct so it matches the __gdtoa prototype declaration.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
mingw-w64-crt/stdio/mingw_pformat.c | 65 ++---
1 file changed, 3 insertions(+), 62 deletions(-)
diff --git a/mingw-w
off-by: Jonathan Yong <10wa...@gmail.com>
---
mingw-w64-crt/stdio/mingw_pformat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/stdio/mingw_pformat.c b/mingw-w64-crt/stdio/mingw_pformat.c
index 87902aea2..021c1eb4d 100644
--- a/mingw-w64-crt/stdio/mingw_pformat.c
Mark Harmstone wrote:
diff --git a/mingw-w64-crt/lib-common/dnsapi.def
b/mingw-w64-crt/lib-common/dnsapi.def
index 929deecd6..fae00a0a5 100644
--- a/mingw-w64-crt/lib-common/dnsapi.def
+++ b/mingw-w64-crt/lib-common/dnsapi.def
@@ -28,6 +28,7 @@ DnsAsyncRegisterTerm
DnsCancelQuery
On 11/29/23 10:39, Antonin Décimo wrote:
Fixes a warning from libtoolize: 'AC_PROG_RANLIB' is rendered obsolete
by 'LT_INIT'.
Signed-off-by: Antonin Décimo
---
mingw-w64-libraries/winpthreads/configure| 104 +--
mingw-w64-libraries/winpthreads/conf
Mind that Clang also does *not* currently define `__STDC_NO_THREADS__`
for MinGW target. For MSVC target, this define was added in
<https://reviews.llvm.org/D112081>. Some of that discussion may also
apply here.
With glibc, apparently the compiler automatically includes
`stdc-predef.h`
ff-by: Martin Storsjö
---
mingw-w64-crt/cfguard/mingw_cfguard_support.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
index cf4535afd..1e777ebfc 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_supp
rt
of accuracy considerations in this area and kernel is in a better
position to handle it than we are.
Anyway, I realize that a revert to be controversial and don't intend to
insist. Playing with plain GetTickCount is probably worth a try, through.
Jacek
_____
x27;t make sense in the first. The comment claims that system
functions have poor accuracy and then uses a function with the same
accuracy to check that and unnecessary delay wait... I'd say we could
just revert 52f2ce12c6182bd239e4f1bbffcd420997b64b08.
Jacek
_
had an unintended consequence of forcing store apps to always use the
fallback case. Perhaps that is the case now with GetModuleHandle.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
1 - 100 of 687 matches
Mail list logo
