在 2019/5/7 上午6:17, David Mathog 写道:
> Changed the called routine to (see below):
>
> DWORD RunCommand( void *lpParam ){
>
Insert an `__stdcall` before `RunCommand`. The calling convention is
part of the function type.
>>
>>> 2. when run procs is shown as -1, not sure how that happens.
>>
On Tue, May 7, 2019 at 12:17 AM David Mathog wrote:
>
> On 04-May-2019 20:31, Liu Hao wrote:
> > 在 2019/5/4 上午6:16, David Mathog 写道:
>
> Thanks for the feedback, but I'm still nowhere near getting this to
> work.
>
> >>
> >> Issues:
> >>
> >>
> >> 1. Compiler warnings:
> >>
> >> c_spawn_n.c: In
On 04-May-2019 20:31, Liu Hao wrote:
在 2019/5/4 上午6:16, David Mathog 写道:
Thanks for the feedback, but I'm still nowhere near getting this to
work.
Issues:
1. Compiler warnings:
c_spawn_n.c: In function 'main':
c_spawn_n.c:47:13: warning: passing argument 3 of 'CreateThread' from
On 5/6/19 11:18 AM, Martin Storsjö wrote:
UCRT is handled in a separate ifdef further above.
The patch looks good, but I'm curious about possible future changes. It
seems tempting to use UCRT variant for all crts (except problematic ARMs
that have dedicated branch anyway) to unify builds
Looks good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Hi Martin,
All patches look good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On Mon, 6 May 2019 at 12:13, Martin Storsjö wrote:
>
> FWIW, if you have LLVM built as DLLs instead of statically linked into
> LLD, there's some known issues regarding hangs as well. Not sure if this
> is what you're running into though.
>
Thanks for the information. I have seen mention of
On 5/6/19 1:08 PM, Martin Storsjö wrote:
On Mon, 6 May 2019, Jacek Caban wrote:
On 5/6/19 11:18 AM, Martin Storsjö wrote:
UCRT is handled in a separate ifdef further above.
The patch looks good, but I'm curious about possible future changes.
It seems tempting to use UCRT variant for all
On Mon, 6 May 2019, Jacek Caban wrote:
On 5/6/19 11:18 AM, Martin Storsjö wrote:
UCRT is handled in a separate ifdef further above.
The patch looks good, but I'm curious about possible future changes. It seems
tempting to use UCRT variant for all crts (except problematic ARMs that have
On Mon, 6 May 2019, Andrew Ng wrote:
On Tue, 30 Apr 2019 at 04:12, Liu Hao wrote:
在 2019/4/30 上午1:45, Andrew Ng 写道:
> I have tried out this patch and it appears to resolve the main LLD
deadlock
> issues. Some deadlocks still occur when running the LLD test suite, but
> this is kind of
While nobody in their right mind should be calling this function,
it is needed for linking a shared libssp (stack smashing protection)
with that crt.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 6 --
mingw-w64-crt/stdio/gets.c | 19 +++
2 files changed,
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/_mingw_stat64.h | 2 +-
mingw-w64-headers/crt/conio.h | 8 +++---
mingw-w64-headers/crt/corecrt.h | 2 +-
mingw-w64-headers/crt/ctype.h | 8 +++---
mingw-w64-headers/crt/inttypes.h| 2 +-
UCRT is handled in a separate ifdef further above.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/stdlib.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 45f03807a..a8cc106df 100644
---
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/crt/ucrtbase_compat.c| 2 +-
mingw-w64-crt/stdio/ucrt__snwprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt__vsnprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt__vsnwprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_fprintf.c | 2 +-
This tries to maintain backwards compatibility of enabling UCRT if
either 0xE00 or 0x1400 is specified, but will break user code that
check the value of __MSVCRT_VERSION__ >= 0x1400.
This tries to correct the historical mistake in how the higher values of
this constant is defined, before it goes
From: Jacek Caban
This can be used both by defining it externally, for setting
__MSVCRT_VERSION__ to the right value, or by checking if _UCRT is
defined.
Signed-off-by: Martin Storsjo
---
mingw-w64-headers/crt/_mingw.h.in | 6 +-
mingw-w64-headers/crt/corecrt.h | 4
2 files
On Mon, 6 May 2019, Jacek Caban wrote:
Hi Martin,
All patches look good to me.
Thanks! So you agree that it should practically be safe to change the
value of this define and very few external users should be hit by the
change? (In practice I have only recently added such checks in one
On Tue, 30 Apr 2019 at 04:12, Liu Hao wrote:
> 在 2019/4/30 上午1:45, Andrew Ng 写道:
> > I have tried out this patch and it appears to resolve the main LLD
> deadlock
> > issues. Some deadlocks still occur when running the LLD test suite, but
> > this is kind of expected.
> >
>
> hmm what caused
On Mon, 6 May 2019, Jacek Caban wrote:
On 5/6/19 1:10 PM, Martin Storsjö wrote:
On Mon, 6 May 2019, Jacek Caban wrote:
Hi Martin,
All patches look good to me.
Thanks! So you agree that it should practically be safe to change the value
of this define and very few external users should be
On 5/6/19 1:10 PM, Martin Storsjö wrote:
On Mon, 6 May 2019, Jacek Caban wrote:
Hi Martin,
All patches look good to me.
Thanks! So you agree that it should practically be safe to change the
value of this define and very few external users should be hit by the
change? (In practice I have
This dll doesn't provide this function, but making it an empty no-op
function should be fine.
This somewhat allows running exes linked against this dll; the previous
incorrect declaration of this function in the def files allowed
compiling projects (where configure checks otherwise would fail
21 matches
Mail list logo
