Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.

[Ozkan Sezer]

Well, I'll be leavinig this to your guys' capable hands.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.

[Ozkan Sezer]

On 10/30/23, Ozkan Sezer  wrote:
> On 10/30/23, Jeremy Drake via Mingw-w64-public
>  wrote:
>> On Tue, 24 Oct 2023, Ozkan Sezer wrote:
>>
>>> LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
>>
>>
>> How does this play out with winstore apps using winstorecompat?  It seems
>> that GetModuleHandle in winstorecompat always returns NULL, while
>> LoadLibrary ends up calling LoadPackagedLibrary.  I have never actually
>> written such apps, so I don't know what LoadPackagedLibrary would return
>> for kernel32.dll.
>>
>> I was actually originally thinking an implementation of GetProcAddress
>> was
>> provided to always return NULL, and that adding "support" for win 98
>> might
>> have had an unintended consequence of forcing store apps to always use
>> the
>> fallback case.  Perhaps that is the case now with GetModuleHandle.
>
> I have no idea about store apps, sorry.

However, maybe something like the following can be done. (Not even
compile-tested, and don't know whether it's correct - just showing
the idea. Someone more familiar with winstrore should mess with it
And also note that clock.c also has a GetModuleHandle use which is
not mine..)

diff --git a/mingw-w64-libraries/winpthreads/src/misc.c
b/mingw-w64-libraries/winpthreads/src/misc.c
index 79c01f2..7db5e91 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -22,2 +22,3 @@

+#include 
 #include "pthread.h"
@@ -30,3 +31,7 @@
 {
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+  GetTickCount64FuncPtr = GetTickCount64;
+#else
   GetTickCount64FuncPtr = (__typeof__(GetTickCount64FuncPtr))
GetProcAddress(GetModuleHandle("kernel32.dll"), "GetTickCount64");
+#endif
 }
diff --git a/mingw-w64-libraries/winpthreads/src/thread.c
b/mingw-w64-libraries/winpthreads/src/thread.c
index 2eb76db..1da0568 100644
--- a/mingw-w64-libraries/winpthreads/src/thread.c
+++ b/mingw-w64-libraries/winpthreads/src/thread.c
@@ -22,2 +22,3 @@

+#include 
 #include 
@@ -83,2 +84,6 @@
 {
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+  AddVectoredExceptionHandlerFuncPtr = AddVectoredExceptionHandler;
+  RemoveVectoredExceptionHandlerFuncPtr = RemoveVectoredExceptionHandler;
+#else
   HMODULE module = GetModuleHandle("kernel32.dll");
@@ -86,2 +91,3 @@
   RemoveVectoredExceptionHandlerFuncPtr =
(__typeof__(RemoveVectoredExceptionHandlerFuncPtr))
GetProcAddress(module, "RemoveVectoredExceptionHandler");
+#endif
 }


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.

[Ozkan Sezer]

On 10/30/23, Jeremy Drake via Mingw-w64-public
 wrote:
> On Tue, 24 Oct 2023, Ozkan Sezer wrote:
>
>> LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
>
>
> How does this play out with winstore apps using winstorecompat?  It seems
> that GetModuleHandle in winstorecompat always returns NULL, while
> LoadLibrary ends up calling LoadPackagedLibrary.  I have never actually
> written such apps, so I don't know what LoadPackagedLibrary would return
> for kernel32.dll.
>
> I was actually originally thinking an implementation of GetProcAddress was
> provided to always return NULL, and that adding "support" for win 98 might
> have had an unintended consequence of forcing store apps to always use the
> fallback case.  Perhaps that is the case now with GetModuleHandle.

I have no idea about store apps, sorry.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.

[Ozkan Sezer]

On 10/24/23, LIU Hao  wrote:
> 在 2023-10-24 22:20, Ozkan Sezer 写道:
>> LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
>
> This patch looks good to me. Please go ahead and apply.
>
> --
> Best regards,
> LIU Hao
>
>

Pushed as b57612d46f97eff0edf419a593c38597b39ca86d
--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.

[Ozkan Sezer]

LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.

--
O.S.
From d835bc5e2b141e596ca38cb193c311d80163c2e6 Mon Sep 17 00:00:00 2001
From: Ozkan Sezer 
Date: Tue, 24 Oct 2023 17:11:04 +0300
Subject: [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after 
cb7f42e.

---
 mingw-w64-libraries/winpthreads/src/misc.c   |5 +
 mingw-w64-libraries/winpthreads/src/thread.c |4 +---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index 0b5e493..79c01f2 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -28,10 +28,7 @@ static ULONGLONG (*GetTickCount64FuncPtr) (VOID);
 
 static void __attribute__((constructor)) ctor (void)
 {
-  HMODULE module = LoadLibrary("kernel32.dll");
-  if (module == NULL) return;
-
-  GetTickCount64FuncPtr = (__typeof__(GetTickCount64FuncPtr)) 
GetProcAddress(module, "GetTickCount64");
+  GetTickCount64FuncPtr = (__typeof__(GetTickCount64FuncPtr)) 
GetProcAddress(GetModuleHandle("kernel32.dll"), "GetTickCount64");
 }
 
 unsigned long long _pthread_time_in_ms(void)
diff --git a/mingw-w64-libraries/winpthreads/src/thread.c 
b/mingw-w64-libraries/winpthreads/src/thread.c
index e2eeaaf..2eb76db 100644
--- a/mingw-w64-libraries/winpthreads/src/thread.c
+++ b/mingw-w64-libraries/winpthreads/src/thread.c
@@ -81,9 +81,7 @@ static ULONG (*RemoveVectoredExceptionHandlerFuncPtr) (PVOID);
 static void __attribute__((constructor))
 ctor (void)
 {
-  HMODULE module = LoadLibrary("kernel32.dll");
-  if (module == NULL) return;
-
+  HMODULE module = GetModuleHandle("kernel32.dll");
   AddVectoredExceptionHandlerFuncPtr = 
(__typeof__(AddVectoredExceptionHandlerFuncPtr)) GetProcAddress(module, 
"AddVectoredExceptionHandler");
   RemoveVectoredExceptionHandlerFuncPtr = 
(__typeof__(RemoveVectoredExceptionHandlerFuncPtr)) GetProcAddress(module, 
"RemoveVectoredExceptionHandler");
 }
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

On 7/15/22, LIU Hao  wrote:
> 在 2022-07-15 01:18, Ozkan Sezer 写道:
>>
>> If there are no objections, I will apply the patches to v5.x and v6.x
>> branches tomorrow.
>>
>
> There is no objection on my side.

OK, applied patches to v5.x and v6.x. Thanks.

v5.x: 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/715ecca90d57f240ea68561e95bfe3ce7e912202/
v6.x: 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/7b26999f1dad11bfba0d1f1735df38dfbea5a7b1/


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

On 7/13/22, Ozkan Sezer  wrote:
> On 7/13/22, Jacek Caban  wrote:
[...]
>> I think that those patches are too invasive for stable branches,
>> especially very old ones like v2.
>
> v5 and v6 then?

If there are no objections, I will apply the patches to v5.x and v6.x
branches tomorrow.

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

On 7/13/22, Jacek Caban  wrote:
> On 7/13/22 11:45, Ozkan Sezer wrote:
>> On 7/13/22, LIU Hao  wrote:
>>> 在 2022/7/12 15:50, Ozkan Sezer 写道:
>>>> With the patch applied to v5.x branch and crt rebuilt, the game engine
>>>> rebuilt with -fno-asynchronous-unwind-tables in the CFLAGS against the
>>>> newly built crt and setjmp.h seems to behave as it is supposed to when
>>>> it hits longjmp.
>>>>
>>> Do the patches replace `setjmp()` with something that does not unwind
>>> the
>>> stack? Looks so but it was
>>> not I that authored the patches, so...
>
> Yes.
>
>> CC'ing Martin and Jacek. Patches against branches v6.x to v2.x
>> re-attached.
>
>
> I think that those patches are too invasive for stable branches,
> especially very old ones like v2.

v5 and v6 then?

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

On 7/13/22, LIU Hao  wrote:
> 在 2022/7/12 15:50, Ozkan Sezer 写道:
>>
>> With the patch applied to v5.x branch and crt rebuilt, the game engine
>> rebuilt with -fno-asynchronous-unwind-tables in the CFLAGS against the
>> newly built crt and setjmp.h seems to behave as it is supposed to when
>> it hits longjmp.
>>
>
> Do the patches replace `setjmp()` with something that does not unwind the
> stack? Looks so but it was
> not I that authored the patches, so...

CC'ing Martin and Jacek. Patches against branches v6.x to v2.x re-attached.

--
O.S.
From 5431a1e7907d5bf40a5ce1092c17c4069cd73865 Mon Sep 17 00:00:00 2001
From: Ozkan Sezer 
Date: Tue, 12 Jul 2022 08:05:40 +0300
Subject: [PATCH] backported setjmp/longjmp changes from v7.x branch:

Hand-picked from commits 02390fa9c1, 436ad4b830, and 844cb490ab:
- Only use _setjmp3 on i386.  Don't use _WIN64 to decide this, but
  check explicitly for i386, and use _setjmp on other platforms.
- setjmp.h: Only pass a frame pointer to setjmp if SEH is enabled
  This should avoid the need for clearing the frame pointer in the
  longjmp wrapper.
- crt: Use importlibs for longjmp.

Fixes setjmp/longjmp code built with -fno-asynchronous-unwind-tables
with SEH toolchains.
---
 mingw-w64-crt/def-include/msvcrt-common.def.in |4 ++--
 mingw-w64-crt/lib32/crtdll.def |2 +-
 mingw-w64-crt/lib64/ntdll.def  |2 +-
 mingw-w64-crt/misc/mingw_getsp.S   |   23 ---
 mingw-w64-headers/crt/setjmp.h |   13 +++--
 5 files changed, 11 insertions(+), 33 deletions(-)

diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 76e1fa3..a27fd22 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -125,11 +125,11 @@ ADD_UNDERSCORE(hypot)
 ;logb
 ADD_UNDERSCORE(nextafter)
 
+longjmp
+
 _daylight DATA
 _timezone DATA
 _tzname DATA
 ADD_UNDERSCORE(daylight)
 ADD_UNDERSCORE(timezone)
 ADD_UNDERSCORE(tzname)
-
-longjmp DATA
diff --git a/mingw-w64-crt/lib32/crtdll.def b/mingw-w64-crt/lib32/crtdll.def
index 1c73001..38e300a 100644
--- a/mingw-w64-crt/lib32/crtdll.def
+++ b/mingw-w64-crt/lib32/crtdll.def
@@ -598,7 +598,7 @@ localtime DATA
 ;_localtime32 = localtime
 log
 log10
-longjmp DATA
+longjmp
 malloc
 mblen
 mbstowcs
diff --git a/mingw-w64-crt/lib64/ntdll.def b/mingw-w64-crt/lib64/ntdll.def
index cc81a06..d08f498 100644
--- a/mingw-w64-crt/lib64/ntdll.def
+++ b/mingw-w64-crt/lib64/ntdll.def
@@ -1963,7 +1963,7 @@ iswxdigit
 isxdigit
 labs
 log
-longjmp DATA
+longjmp
 mbstowcs
 memchr
 memcmp
diff --git a/mingw-w64-crt/misc/mingw_getsp.S b/mingw-w64-crt/misc/mingw_getsp.S
index 3c99658..7992abd 100644
--- a/mingw-w64-crt/misc/mingw_getsp.S
+++ b/mingw-w64-crt/misc/mingw_getsp.S
@@ -25,26 +25,3 @@ __MINGW_USYMBOL(mingw_getsp):
 	mov	r0, sp
 	bx	lr
 #endif
-
-/* On ARM:
- * Error: cannot represent BFD_RELOC_32_PCREL relocation in this object file format
- * But anyway, nothing is needed here as libarm32/libmsvcrt.a is exporting longjmp
-  ldr ip, 1f
-  ldr pc, [pc, ip]
-  1: .long __imp_longjmp - (1b + 4)
-*/
-#if !(defined(_ARM_) || defined(__arm__))
-	.globl __MINGW_USYMBOL(longjmp)
-	.def	__MINGW_USYMBOL(longjmp);	.scl	2;	.type	32;	.endef
-__MINGW_USYMBOL(longjmp):
-#if defined(_AMD64_) || defined(__x86_64__)
-#ifndef __SEH__
-  xorq %rax,%rax
-  movq %rax, (%rcx)
-#endif
-  leaq __MINGW_IMP_LSYMBOL(longjmp)(%rip), %rax
-  jmpq *(%rax)
-#elif defined(_X86_) || defined(__i386__)
-  jmp *__imp__longjmp
-#endif
-#endif /* !(defined(_ARM_) || defined(__arm__)) */
diff --git a/mingw-w64-headers/crt/setjmp.h b/mingw-w64-headers/crt/setjmp.h
index 5be566d..d116bd4 100644
--- a/mingw-w64-headers/crt/setjmp.h
+++ b/mingw-w64-headers/crt/setjmp.h
@@ -169,24 +169,28 @@ extern "C" {
 #define _JMP_BUF_DEFINED
 #endif
 
+_CRTIMP __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void __cdecl longjmp(jmp_buf _Buf,int _Value);
+
 void * __cdecl __attribute__ ((__nothrow__)) mingw_getsp (void);
 
 #ifndef USE_NO_MINGW_SETJMP_TWO_ARGS
 #  ifndef _INC_SETJMPEX
-#ifdef _WIN64
+#if defined(_X86_) || defined(__i386__)
+#  define setjmp(BUF) _setjmp3((BUF), NULL)
+#elif defined(__SEH__)
 # if (__MINGW_GCC_VERSION < 40702)
 #  define setjmp(BUF) _setjmp((BUF), mingw_getsp())
 # else
 #  define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
 # endif
 #else
-#  define setjmp(BUF) _setjmp3((BUF), NULL)
+# define setjmp(BUF) _setjmp((BUF), NULL)
 #endif
   int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) _setjmp(jmp_buf _Buf, void *_Ctx);
   int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) _setjmp3(jmp_buf _Buf, void *_Ctx);
 #  else
 #undef setjmp
-#ifdef _WIN64
+#ifdef __SEH__
 # if (__MINGW_GCC_VERSION < 40702)
 #  define setjmp(BUF) _setjmpe

Re: [Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

On 7/12/22, Ozkan Sezer  wrote:
[...]
> My toolchain is a SEH one, and -fno-asynchronous-unwind-tables inhibits
> defining of the __SEH__ macro apparently.  v7.x seems to improve on the
> matter, ie. the following three patches' backport _should_ do the trick,
> the last two seems to be the key:
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/02390fa9c1dd6d3870fa5f5f1b0cf702f1267362/
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/436ad4b83035937125e8e596893269ff4f1fe662/
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/844cb490ab2cc32ac3df5914700564b2e40739d8/
>
> Is the attached patch against v5.x correct? (haven't tested yet..)

With the patch applied to v5.x branch and crt rebuilt, the game engine
rebuilt with -fno-asynchronous-unwind-tables in the CFLAGS against the
newly built crt and setjmp.h seems to behave as it is supposed to when
it hits longjmp.

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

On 7/12/22, LIU Hao  wrote:
> 在 2022/7/12 09:18, Ozkan Sezer 写道:
>> I hit this curiosity when I built quakespasm [1] for x64 using gcc-7.5.0
>> against mingw-w64 v5.x branch:  Hitting longjmp crashes when built using
>> -fno-asynchronous-unwind-tables gcc switch but works properly without it.
>> Anyone has any insight into this? (And yes I know that the v5.x branch is
>> old but the toolchain has been available.)
>>
>
> Is it because that `longjmp()` unwinds the stack on Windows x64, but not on
> x86 or other operating
> systems?
>

My toolchain is a SEH one, and -fno-asynchronous-unwind-tables inhibits
defining of the __SEH__ macro apparently.  v7.x seems to improve on the
matter, ie. the following three patches' backport _should_ do the trick,
the last two seems to be the key:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/02390fa9c1dd6d3870fa5f5f1b0cf702f1267362/
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/436ad4b83035937125e8e596893269ff4f1fe662/
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/844cb490ab2cc32ac3df5914700564b2e40739d8/

Is the attached patch against v5.x correct? (haven't tested yet..)

--
O.S.
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in 
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 76e1fa3..a27fd22 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -125,11 +125,11 @@ ADD_UNDERSCORE(hypot)
 ;logb
 ADD_UNDERSCORE(nextafter)
 
+longjmp
+
 _daylight DATA
 _timezone DATA
 _tzname DATA
 ADD_UNDERSCORE(daylight)
 ADD_UNDERSCORE(timezone)
 ADD_UNDERSCORE(tzname)
-
-longjmp DATA
diff --git a/mingw-w64-crt/lib32/crtdll.def b/mingw-w64-crt/lib32/crtdll.def
index 1c73001..38e300a 100644
--- a/mingw-w64-crt/lib32/crtdll.def
+++ b/mingw-w64-crt/lib32/crtdll.def
@@ -598,7 +598,7 @@ localtime DATA
 ;_localtime32 = localtime
 log
 log10
-longjmp DATA
+longjmp
 malloc
 mblen
 mbstowcs
diff --git a/mingw-w64-crt/lib64/ntdll.def b/mingw-w64-crt/lib64/ntdll.def
index cc81a06..d08f498 100644
--- a/mingw-w64-crt/lib64/ntdll.def
+++ b/mingw-w64-crt/lib64/ntdll.def
@@ -1963,7 +1963,7 @@ iswxdigit
 isxdigit
 labs
 log
-longjmp DATA
+longjmp
 mbstowcs
 memchr
 memcmp
diff --git a/mingw-w64-crt/misc/mingw_getsp.S b/mingw-w64-crt/misc/mingw_getsp.S
index 3c99658..7992abd 100644
--- a/mingw-w64-crt/misc/mingw_getsp.S
+++ b/mingw-w64-crt/misc/mingw_getsp.S
@@ -25,26 +25,3 @@ __MINGW_USYMBOL(mingw_getsp):
mov r0, sp
bx  lr
 #endif
-
-/* On ARM:
- * Error: cannot represent BFD_RELOC_32_PCREL relocation in this object file 
format
- * But anyway, nothing is needed here as libarm32/libmsvcrt.a is exporting 
longjmp
-  ldr ip, 1f
-  ldr pc, [pc, ip]
-  1: .long __imp_longjmp - (1b + 4)
-*/
-#if !(defined(_ARM_) || defined(__arm__))
-   .globl __MINGW_USYMBOL(longjmp)
-   .def__MINGW_USYMBOL(longjmp);   .scl2;  .type   32; 
.endef
-__MINGW_USYMBOL(longjmp):
-#if defined(_AMD64_) || defined(__x86_64__)
-#ifndef __SEH__
-  xorq %rax,%rax
-  movq %rax, (%rcx)
-#endif
-  leaq __MINGW_IMP_LSYMBOL(longjmp)(%rip), %rax
-  jmpq *(%rax)
-#elif defined(_X86_) || defined(__i386__)
-  jmp *__imp__longjmp
-#endif
-#endif /* !(defined(_ARM_) || defined(__arm__)) */
diff --git a/mingw-w64-headers/crt/setjmp.h b/mingw-w64-headers/crt/setjmp.h
index 5be566d..d116bd4 100644
--- a/mingw-w64-headers/crt/setjmp.h
+++ b/mingw-w64-headers/crt/setjmp.h
@@ -169,24 +169,28 @@ extern "C" {
 #define _JMP_BUF_DEFINED
 #endif
 
+_CRTIMP __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void __cdecl 
longjmp(jmp_buf _Buf,int _Value);
+
 void * __cdecl __attribute__ ((__nothrow__)) mingw_getsp (void);
 
 #ifndef USE_NO_MINGW_SETJMP_TWO_ARGS
 #  ifndef _INC_SETJMPEX
-#ifdef _WIN64
+#if defined(_X86_) || defined(__i386__)
+#  define setjmp(BUF) _setjmp3((BUF), NULL)
+#elif defined(__SEH__)
 # if (__MINGW_GCC_VERSION < 40702)
 #  define setjmp(BUF) _setjmp((BUF), mingw_getsp())
 # else
 #  define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
 # endif
 #else
-#  define setjmp(BUF) _setjmp3((BUF), NULL)
+# define setjmp(BUF) _setjmp((BUF), NULL)
 #endif
   int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) _setjmp(jmp_buf 
_Buf, void *_Ctx);
   int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) _setjmp3(jmp_buf 
_Buf, void *_Ctx);
 #  else
 #undef setjmp
-#ifdef _WIN64
+#ifdef __SEH__
 # if (__MINGW_GCC_VERSION < 40702)
 #  define setjmp(BUF) _setjmpex((BUF), mingw_getsp())
 #  define setjmpex(BUF) _setjmpex((BUF), mingw_getsp())
@@ -210,9 +214,6 @@ void * __cdecl __attribute__ ((__nothrow__)) mingw_getsp 
(void);
   int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) setjmp(jmp_buf 
_Buf);
 #endif
 
-  __declspec(noreturn) __attribute__ ((__nothrow__)) void __cdecl 
ms_longjmp(jmp_buf _Buf,int _Value)/* throw(...)*/;
-  __

[Mingw-w64-public] x64 longjmp and -fno-asynchronous-unwind-tables

[Ozkan Sezer]

I hit this curiosity when I built quakespasm [1] for x64 using gcc-7.5.0
against mingw-w64 v5.x branch:  Hitting longjmp crashes when built using
-fno-asynchronous-unwind-tables gcc switch but works properly without it.
Anyone has any insight into this? (And yes I know that the v5.x branch is
old but the toolchain has been available.)

--
O.S.

[1] https://sourceforge.net/projects/quakespasm/


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] -Warray-bounds warning for __readfsdword and __readgsqword

[Ozkan Sezer]

On 6/29/22, LIU Hao  wrote:
> The compiler sees
>
>  := *(unsigned long*) 42
>
> which itself is indeed dereferencing a strange pointer. Probably GCC should
> warn about only pointers
> to known data.

Lazy solution for me would be something like the following:
Does it look correct?

#if defined(__MINGW32__) && defined(__x86_64__)
#undef NtCurrentTeb
#define NtCurrentTeb MI_NtCurrentTeb
struct _TEB * MI_NtCurrentTeb(void) {
  void *ret;
  __asm__ __volatile__ ("movq %%gs:0x30,%0" : "=r" (ret));
  return ret;
}
#elif defined(__MINGW32__) && defined(__i386__)
#undef NtCurrentTeb
#define NtCurrentTeb MI_NtCurrentTeb
struct _TEB * MI_NtCurrentTeb(void) {
  void *ret;
  __asm__ __volatile__ ("movl %%fs:0x18,%0" : "=r" (ret));
  return ret;
}
#endif


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] (no subject)

[Ozkan Sezer]

> The compiler sees
>
>  := *(unsigned long*) 42
>
> which itself is indeed dereferencing a strange pointer. Probably GCC should
> warn about only pointers
> to known data.

Lazy solution for me would be something like the following:
Does it look correct?

#if defined(__MINGW32__) && defined(__x86_64__)
#undef NtCurrentTeb
#define NtCurrentTeb MI_NtCurrentTeb
struct _TEB * MI_NtCurrentTeb(void) {
  void *ret;
  __asm__ __volatile__ ("movq %%gs:0x30,%0" : "=r" (ret));
  return ret;
}
#elif defined(__MINGW32__) && defined(__i386__)
#undef NtCurrentTeb
#define NtCurrentTeb MI_NtCurrentTeb
struct _TEB * MI_NtCurrentTeb(void) {
  void *ret;
  __asm__ __volatile__ ("movl %%fs:0x18,%0" : "=r" (ret));
  return ret;
}
#endif


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] -Warray-bounds warning for __readfsdword and __readgsqword

[Ozkan Sezer]

On 6/29/22, Ozkan Sezer  wrote:
> On 6/29/22, LIU Hao  wrote:
>> I have been aware of this too. The asm statement is passed an indirection
>> by
>> a constant offset in
>> the FS/GS segment, which itself is valid, but GCC thinks it was about the
>> default DS segment and
>> fails to calculate its size.
>>
>>
>> This may be solved for GCC by casting the input offset to a pointer to an
>> array of unknown bound. So
>> instead of writing
>>
>>[offset] "m" ((*(y *) (size_t) Offset))
>>
>> we write
>>
>>[offset] "m" ((*(y (*)[]) (size_t) Offset))
>>
>>
>> Unfortunately Clang does not like this:
>>
>>test.c:5:53: error: dereference of pointer to incomplete type
>> 'unsigned
>> long[]'
>>
>> Probably some conditional macros are necessary.
>
> Well, I'm not proficient with gcc inline asm.
> So, whatever you guys think is best.

Also: is this not actually a gcc bug? Are they aware of it?


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] -Warray-bounds warning for __readfsdword and __readgsqword

[Ozkan Sezer]

On 6/29/22, LIU Hao  wrote:
> I have been aware of this too. The asm statement is passed an indirection by
> a constant offset in
> the FS/GS segment, which itself is valid, but GCC thinks it was about the
> default DS segment and
> fails to calculate its size.
>
>
> This may be solved for GCC by casting the input offset to a pointer to an
> array of unknown bound. So
> instead of writing
>
>[offset] "m" ((*(y *) (size_t) Offset))
>
> we write
>
>[offset] "m" ((*(y (*)[]) (size_t) Offset))
>
>
> Unfortunately Clang does not like this:
>
>test.c:5:53: error: dereference of pointer to incomplete type 'unsigned
> long[]'
>
> Probably some conditional macros are necessary.

Well, I'm not proficient with gcc inline asm.
So, whatever you guys think is best.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] -Warray-bounds warning for __readfsdword and __readgsqword

[Ozkan Sezer]

Noticed this in github CI runs of vkQuake. Is the warning bogus?

In function '__readfsdword',
inlined from 'NtCurrentTeb' at
D:/a/_temp/msys64/mingw32/include/winnt.h:2438:27,
inlined from '_mi_thread_id' at mimalloc/mimalloc-internal.h:814:21,
inlined from '_mi_is_main_thread' at mimalloc/init.c:408:68,
inlined from 'mi_vfprintf_thread.constprop' at mimalloc/options.c:347:50:
D:/a/_temp/msys64/mingw32/include/psdk_inc/intrin-impl.h:2164:1:
warning: array subscript 0 is outside array bounds of 'long unsigned
int[0]' [-Warray-bounds]
 2164 | __buildreadseg(__readfsdword, unsigned __LONG32, "fs", "l")
  | ^~


In function '__readgsqword',
inlined from 'NtCurrentTeb' at
D:/a/_temp/msys64/mingw64/include/winnt.h:9292:73,
inlined from '_mi_thread_id' at mimalloc/mimalloc-internal.h:814:21,
inlined from '_mi_is_main_thread' at mimalloc/init.c:408:68:
D:/a/_temp/msys64/mingw64/include/psdk_inc/intrin-impl.h:838:1:
warning: array subscript 0 is outside array bounds of 'long long
unsigned int[0]' [-Warray-bounds]
  838 | __buildreadseg(__readgsqword, unsigned __int64, "gs", "q")
  | ^~


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] headers: Fix parameter types in oleauto.h

[Ozkan Sezer]

On 6/19/22, Biswapriyo Nath  wrote:
>

I guess this is for https://sourceforge.net/p/mingw-w64/bugs/940/

The issue tracker has become a zombie for quite some time: there
are still issues there need attending to and people who don't know
(and really, they don't need to know) are still posting issues in
there instead of the mailing list. I wish that were rectified some
day..

The patch itself looked OK to me BTW, after a brief look..

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] bug #864: _ftelli64 returns wrong values with MinGW-w64 32-bit

[Ozkan Sezer]

On 6/6/22, LIU Hao  wrote:
> 在 2022-06-06 22:07, Ozkan Sezer 写道:
>> On 6/6/22, LIU Hao  wrote:
>>> 在 2022-06-06 11:01, Ozkan Sezer 写道:
>>>> This is a curious one: https://sourceforge.net/p/mingw-w64/bugs/864/
>>>>
>>>
>>> I just tried compiling and running the 'crt_ftell.c' with latest
>>> mingw-w64
>>> and GCC 12, on both
>>> Windows 10 and Windows 7 x64; neither reproduced the suspicious result.
>>
>> They report that they have the issue with x86 builds, not x64. (Haven't
>> tried myself, not yet at least.)
>
> Yes, x86 builds on x64 systems.

Oh, I see.

That bug entry needs updating I guess.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] bug #864: _ftelli64 returns wrong values with MinGW-w64 32-bit

[Ozkan Sezer]

On 6/6/22, LIU Hao  wrote:
> 在 2022-06-06 11:01, Ozkan Sezer 写道:
>> This is a curious one: https://sourceforge.net/p/mingw-w64/bugs/864/
>>
>
> I just tried compiling and running the 'crt_ftell.c' with latest mingw-w64
> and GCC 12, on both
> Windows 10 and Windows 7 x64; neither reproduced the suspicious result.

They report that they have the issue with x86 builds, not x64. (Haven't
tried myself, not yet at least.)


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] bug #864: _ftelli64 returns wrong values with MinGW-w64 32-bit

[Ozkan Sezer]

This is a curious one: https://sourceforge.net/p/mingw-w64/bugs/864/

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] lrint on x64

[Ozkan Sezer]

On 6/5/22, LIU Hao  wrote:
> 在 2022-06-05 19:30, Ozkan Sezer 写道:
>> On 6/5/22, LIU Hao  wrote:
>>> 在 2022-06-03 22:03, Ozkan Sezer 写道:
>>>>
>>>> A quick x64 build ran under win10 yielded the same results.
>>>>
>>>
>>> As far as I can tell, `CVTSD2SI` should be preferred to `FISTP` for
>>> `float`
>>> and `double`. The X87
>>> implementation was added in 2007 and has not been updated since ever.
>>
>> Should I push changes to lrint.c and lrintf.c, then?
>> (Won't be touching llrint.c)
>
> Those changes look good to me. Please go ahead.

Change pushed as
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/568ddf198ac1ab44773482c272c046b75eefd746/

> BTW, I think we can move a bit further: Check for `__SSE2__` instead of
> `__x86_64__`. This enables
> SSE2 code for x86 when, for example, `-march=pentium4` is enabled, which is
> now the default for
> MSYS2. It's worth another patch, though.

Feel free to do so.

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] lrint on x64

[Ozkan Sezer]

On 6/5/22, LIU Hao  wrote:
> 在 2022-06-03 22:03, Ozkan Sezer 写道:
>>
>> A quick x64 build ran under win10 yielded the same results.
>>
>
> As far as I can tell, `CVTSD2SI` should be preferred to `FISTP` for `float`
> and `double`. The X87
> implementation was added in 2007 and has not been updated since ever.

Should I push changes to lrint.c and lrintf.c, then?
(Won't be touching llrint.c)


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] lrint on x64

[Ozkan Sezer]

>> For the other functions, do the SSE intrinsics honor the rounding
>> mode/direction that you've set fesetround()?
>>
>> // Martin
>
> Documentation [1] doesn't seem to have such detail.
>
> Haven't booted to windows, but ran the following on i686 linux:
>
> #include 
> #include 
> #include 
> #include 
> #include 
>
> static __inline long lrint_x87(double _x) {
> long val;
> __asm__ __volatile__ ("fistpl %0" : "=m" (val) : "t" (_x) : "st");
> return val;
> }
>
> int main (int argc, char **argv)
> {
> long x87, sse2;
> double d;
> if (argc != 2) return -1;
> d = atof(argv[1]);
> fesetround(FE_DOWNWARD);
> x87 = lrint_x87(d);
> sse2 = _mm_cvtsd_si32(_mm_load_sd());
> printf("%ld, %ld\n", x87, sse2);
> return 0;
> }
>
> If I keep the fesetround(FE_DOWNWARD); line uncommented,
> it prints 1 for 1.999 instead of 2.

A quick x64 build ran under win10 yielded the same results.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] lrint on x64

[Ozkan Sezer]

On 6/3/22, Martin Storsjö  wrote:
>
> For long double, I would presume that you'd still need to use x87, as SSE
> can't handle 80 bit long doubles, right? (Or converting down to a plain
> double first, then using SSE, probably also works - but I guess that also
> might generate x87 instructions.)

I wasn't sure about long double anyway, won't touch that.

> For the other functions, do the SSE intrinsics honor the rounding
> mode/direction that you've set fesetround()?
>
> // Martin

Documentation [1] doesn't seem to have such detail.

Haven't booted to windows, but ran the following on i686 linux:

#include 
#include 
#include 
#include 
#include 

static __inline long lrint_x87(double _x) {
long val;
__asm__ __volatile__ ("fistpl %0" : "=m" (val) : "t" (_x) : "st");
return val;
}

int main (int argc, char **argv)
{
long x87, sse2;
double d;
if (argc != 2) return -1;
d = atof(argv[1]);
fesetround(FE_DOWNWARD);
x87 = lrint_x87(d);
sse2 = _mm_cvtsd_si32(_mm_load_sd());
printf("%ld, %ld\n", x87, sse2);
return 0;
}

If I keep the fesetround(FE_DOWNWARD); line uncommented,
it prints 1 for 1.999 instead of 2.

--
O.S.

[1] 
https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#techs=SSE2_expand=4288,2216,2215=_mm_cvtsd_si32


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] lrint on x64

[Ozkan Sezer]

Why are we using x87 asm instead of sse2 intrinsics for lrint/lrintf ?
E.g.: why not do something like the following?

diff --git a/mingw-w64-crt/math/lrint.c b/mingw-w64-crt/math/lrint.c
index ec80e4e..7831446 100644
--- a/mingw-w64-crt/math/lrint.c
+++ b/mingw-w64-crt/math/lrint.c
@@ -5,10 +5,16 @@
  */
 #include 

+#if defined(_AMD64_) || defined(__x86_64__)
+#include 
+#endif
+
 long lrint (double x)
 {
   long retval = 0L;
+#if defined(_AMD64_) || defined(__x86_64__)
+  retval = _mm_cvtsd_si32(_mm_load_sd());
-#if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) ||
defined(__i386__)
+#elif defined(_X86_) || defined(__i386__)
   __asm__ __volatile__ ("fistpl %0"  : "=m" (retval) : "t" (x) : "st");
 #elif defined(__arm__) || defined(_ARM_)
   float temp;
diff --git a/mingw-w64-crt/math/lrintf.c b/mingw-w64-crt/math/lrintf.c
index 91fc5e1..1e8902f 100644
--- a/mingw-w64-crt/math/lrintf.c
+++ b/mingw-w64-crt/math/lrintf.c
@@ -5,10 +5,16 @@
  */
 #include 

+#if defined(_AMD64_) || defined(__x86_64__)
+#include 
+#endif
+
 long lrintf (float x)
 {
   long retval = 0l;
+#if defined(_AMD64_) || defined(__x86_64__)
+  retval = _mm_cvtss_si32(_mm_load_ss());
-#if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) ||
defined(__i386__)
+#elif defined(_X86_) || defined(__i386__)
   __asm__ __volatile__ ("fistpl %0"  : "=m" (retval) : "t" (x) : "st");
 #elif defined(__arm__) || defined(_ARM_)
   __asm__ __volatile__ (
diff --git a/mingw-w64-crt/math/lrintl.c b/mingw-w64-crt/math/lrintl.c
index d710fac..9f1be51 100644
--- a/mingw-w64-crt/math/lrintl.c
+++ b/mingw-w64-crt/math/lrintl.c
@@ -5,10 +5,16 @@
  */
 #include 

+#if defined(_AMD64_) || defined(__x86_64__)
+#include 
+#endif
+
 long lrintl (long double x)
 {
   long retval = 0l;
+#if defined(_AMD64_) || defined(__x86_64__)
+  retval = _mm_cvtsd_si64(_mm_load_sd());
-#if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) ||
defined(__i386__)
+#elif defined(_X86_) || defined(__i386__)
   __asm__ __volatile__ ("fistpl %0"  : "=m" (retval) : "t" (x) : "st");
 #elif defined(__arm__) || defined(_ARM_) || defined(__aarch64__) ||
defined(_ARM64_)
 retval = lrint(x);

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Unable to cross compile SDL2

[Ozkan Sezer]

On 5/10/22, Christer Solskogen  wrote:
> I'm not sure who's fault it is, but I'm not longer able to cross compile
> SDL2:

https://github.com/libsdl-org/SDL/issues/5589


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] windows.gaming.input.h

[Ozkan Sezer]

On 4/12/22, Biswapriyo Nath  wrote:
> First, need to upstream some interface definitions to wine. I can try
> to send patches in wine today. Does SDL have any tests to check if
> things are working properly (assume it does not need gaming hardware)
> ?

Apart from configure detection of the header and build without warnings,
there is testgamecontroller test program but that needs gaming hw.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] windows.gaming.input.h

[Ozkan Sezer]

Jacek & others:

Any plans to import windows.gaming.input.h and its deps into mingw-w64,
e.g. for SDL2 to compile, assuming it's stable in wine?

Thanks.
--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] winpthreads: Add a missing (void) in the parameters for pthread_getevent

[Ozkan Sezer]

On 2/17/22, Martin Storsjö  wrote:
> On Thu, 17 Feb 2022, NightStrike wrote:
>
>> On Thu, Feb 17, 2022 at 8:27 AM Martin Storsjö  wrote:
>>>
>>> This avoids warnings if building code including it, with
>>> -Wstrict-prototypes. (Latest Clang defaults to enabling this warning
>>> by default.)
>>>
>>> Signed-off-by: Martin Storsjö 
>>> ---
>>>  mingw-w64-libraries/winpthreads/include/pthread.h | 2 +-
>>>  mingw-w64-libraries/winpthreads/src/thread.c  | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h 
>>> b/mingw-w64-libraries/winpthreads/include/pthread.h
>>> index fe0e821ce..5aadb1cfa 100644
>>> --- a/mingw-w64-libraries/winpthreads/include/pthread.h
>>> +++ b/mingw-w64-libraries/winpthreads/include/pthread.h
>>> @@ -393,7 +393,7 @@ int WINPTHREAD_API pthread_barrierattr_getpshared(void 
>>> **attr, int *s);
>>>  /* Private extensions for analysis and internal use.  */
>>>  struct _pthread_cleanup ** WINPTHREAD_API pthread_getclean (void);
>>>  void * WINPTHREAD_API pthread_gethandle (pthread_t t);
>>> -void * WINPTHREAD_API pthread_getevent ();
>>> +void * WINPTHREAD_API pthread_getevent (void);
>>>
>>>  unsigned long long WINPTHREAD_API _pthread_rel_time_in_ms(const
>>> struct timespec *ts);
>>>  unsigned long long WINPTHREAD_API _pthread_time_in_ms(void);
>>> diff --git a/mingw-w64-libraries/winpthreads/src/thread.c
>>> b/mingw-w64-libraries/winpthreads/src/thread.c
>>> index 55361aec9..e3edbae8a 100644
>>> --- a/mingw-w64-libraries/winpthreads/src/thread.c
>>> +++ b/mingw-w64-libraries/winpthreads/src/thread.c
>>> @@ -1038,7 +1038,7 @@ pthread_self (void)
>>>
>>>  /* Internal helper for getting event handle of thread T.  */
>>>  void *
>>> -pthread_getevent ()
>>> +pthread_getevent (void)
>>>  {
>>>_pthread_v *t = __pthread_self_lite ();
>>>return (!t ? NULL : t->evStart);
>>
>> Adding unnecessary spam because of yet another poor choice of clang is
>> not something we should be catering towards.  Users can compile with
>> -Wno-strict-prototypes if it bothers them that much.
>
> Actually, my comment about Clang was wrong, I was misinformed - this
> doesn't have anything to do with Clang at all.
>
> I saw the warning fly by for every file built, when building a project
> that explicitly enables -Wstrict-prototypes.
>
> // Martin

IMO, the patch is good.

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 0/2 v2] headers: add two members missing in partition info

[Ozkan Sezer]

On 8/21/21, Corinna Vinschen  wrote:
> From: Corinna Vinschen 
>
> MSDN documents struct members in partition info not defined in the
> mingw-w64 headers ntdddisk.h and winioctl.h.  Add them.
>
> v2: Add feature tests
>
> Corinna Vinschen (2):
>   headers: add missing PARTITION_INFORMATION_EX member
>   headers: add missing PARTITION_INFORMATION_MBR member
>
>  mingw-w64-headers/include/ntdddisk.h | 2 ++
>  mingw-w64-headers/include/winioctl.h | 2 ++
>  2 files changed, 4 insertions(+)

Applied the two patches to master. Thanks.

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 0/2 v2] headers: add two members missing in partition info

[Ozkan Sezer]

On 8/21/21, Corinna Vinschen  wrote:
> From: Corinna Vinschen 
>
> MSDN documents struct members in partition info not defined in the
> mingw-w64 headers ntdddisk.h and winioctl.h.  Add them.
>
> v2: Add feature tests
>
> Corinna Vinschen (2):
>   headers: add missing PARTITION_INFORMATION_EX member
>   headers: add missing PARTITION_INFORMATION_MBR member

Looks good to me now.

--
O.S.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 0/2] headers: add two members missing in partition info

[Ozkan Sezer]

On 8/21/21, Jeremy Drake via Mingw-w64-public
 wrote:
> On Fri, 20 Aug 2021, Corinna Vinschen wrote:
>
>> On Aug 20 15:46, Ozkan Sezer wrote:
>> > Those members do not exist in win7 versions of ddk headers.
>> > Are they added for newer windows versions support?
>>
>> The documentation doesn't mention that, but I guess they have
>> been added in W10 or so.
>
> I just checked my Windows 10 SDK headers.  The IsServicePartition member
> is wrapped in
> #if (NTDDI_VERSION >= NTDDI_WIN10_RS3)  /* ABRACADABRA_WIN10_RS3 */
>
> The PartitionId member is wrapped in
> #if (NTDDI_VERSION >= NTDDI_WINBLUE)/* ABRACADABRA_THRESHOLD */

Then we need some equivalent ifdef magic here.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 0/2] headers: add two members missing in partition info

[Ozkan Sezer]

On 8/20/21, Corinna Vinschen  wrote:
> From: Corinna Vinschen 
>
> MSDN documents struct members in partition info not defined in the
> mingw-w64 headers ntdddisk.h and winioctl.h.  Add them.
>
> Corinna Vinschen (2):
>   headers: add missing PARTITION_INFORMATION_EX member
>   headers: add missing PARTITION_INFORMATION_MBR member

Those members do not exist in win7 versions of ddk headers.
Are they added for newer windows versions support?


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/2] headers: Don't redirect _mm_malloc to _aligned_malloc

[Ozkan Sezer]

On 12/4/20, Martin Storsjö  wrote:
> The headers have a number of brittle workarounds, all trying to make
> the "#define _mm_malloc _aligned_malloc" redirect in malloc.h work
> properly.

Is this https://sourceforge.net/p/mingw-w64/bugs/192/
(after 10 years) ?

> That define is problematic, because it behaves differently depending
> on the order headers are included. If malloc.h is included before
> GCC's mm_malloc.h, malloc.h does "#define _mm_malloc _aligned_malloc"
> and "#define _MM_MALLOC_H_INCLUDED", making sure that a later include
> of GCC's mm_malloc.h define nothing. If the user code calls
> _mm_malloc() after that, it ends up calling _aligned_malloc().
>
> However, if the user code (implicitly) includes mm_malloc.h before
> malloc.h, the situation is much trickier. (mm_malloc.h gets implicitly
> included by x86intrin.h, which is included by e.g. winnt.h.)
>
> GCC's mm_malloc.h looks like this, a little simplified:
>
> #ifndef _MM_MALLOC_H_INCLUDED
> #define _MM_MALLOC_H_INCLUDED
>
> #include 
>
> static __inline__ void *_mm_malloc (...)
>
> The stdlib.h include implicitly includes malloc.h, which does
> "#define _mm_malloc _aligned_malloc", which causes GCC's mm_malloc.h
> to suddenly define a static inline _aligned_malloc instead.
>
> This has been halfway worked around by not defining the non-inline
> _aligned_malloc in malloc.h if _MM_MALLOC_H_INCLUDED already was
> defined, making the inline function the only definition of it.
>
> So when expanding malloc.h in this context, there's no way to stop the
> outer mm_malloc.h from defining a static inline function, and regardless
> of whatever name it is renamed to with a define, that static inline
> function is what callers to _mm_malloc end up calling.
>
> This causes calls to both _mm_malloc and _aligned_malloc to end
> up either with the dllimported function or the static inline version,
> depending on which header was included first. If one translation unit
> calls _mm_malloc and another one calls _mm_free, there's a risk that
> they end up mismatched, which is potentially fatal.
>
> This was earlier attempted to be worked around in e.g. intrin.h, by
> forcing including malloc.h before x86intrin.h, but such workarounds
> are futile, as user code could also include x86intrin.h, immintrin.h
> or even mm_malloc.h directly, without passing through mingw headers.
>
> Instead just remove the _mm_malloc redefinition and include the
> compiler's mm_malloc.h header. This makes sure that regardless of
> header include order, calls to _aligned_malloc and _mm_malloc will
> always end up to the same function, avoiding risks of mismatches
> between *_malloc and *_free.
>
> This also has the effect of no longer hiding the declaration of
> _aligned_malloc when including intrin.h first.
>
> Signed-off-by: Martin Storsjö 
> ---
>  mingw-w64-headers/crt/intrin.h |  1 -
>  mingw-w64-headers/crt/malloc.h | 17 +++--
>  mingw-w64-headers/crt/stdlib.h |  3 ---
>  3 files changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
> index 0b2343fb8..198c94fc8 100644
> --- a/mingw-w64-headers/crt/intrin.h
> +++ b/mingw-w64-headers/crt/intrin.h
> @@ -60,7 +60,6 @@
>extern unsigned int __builtin_ia32_crc32hi (unsigned int, unsigned
> short);
>extern unsigned int __builtin_ia32_crc32si (unsigned int, unsigned int);
>  #ifndef _MM_MALLOC_H_INCLUDED
> -#define _MM_MALLOC_H_INCLUDED
>  #include 
>  #include 
>  /* Make sure _mm_malloc and _mm_free are defined.  */
> diff --git a/mingw-w64-headers/crt/malloc.h b/mingw-w64-headers/crt/malloc.h
> index e73b70597..13911193f 100644
> --- a/mingw-w64-headers/crt/malloc.h
> +++ b/mingw-w64-headers/crt/malloc.h
> @@ -52,18 +52,6 @@ extern "C" {
>
>extern unsigned int _amblksiz;
>
> -/* Make sure that X86intrin.h doesn't produce here collisions.  */
> -#if (!defined (_XMMINTRIN_H_INCLUDED) && !defined (_MM_MALLOC_H_INCLUDED))
> -#define __DO_ALIGN_DEFINES
> -#endif
> -
> -#ifndef _MM_MALLOC_H_INCLUDED
> -#define _MM_MALLOC_H_INCLUDED
> -#endif
> -
> -#define _mm_free(a) _aligned_free(a)
> -#define _mm_malloc(a,b) _aligned_malloc(a,b)
> -
>  #ifndef _CRT_ALLOCATION_DEFINED
>  #define _CRT_ALLOCATION_DEFINED
>void *__cdecl calloc(size_t _NumOfElements,size_t _SizeOfElements);
> @@ -72,10 +60,8 @@ extern "C" {
>void *__cdecl realloc(void *_Memory,size_t _NewSize);
>_CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t
> _Size);
>
> -#ifdef __DO_ALIGN_DEFINES
>_CRTIMP void __cdecl _aligned_free(void *_Memory);
>_CRTIMP void *__cdecl _aligned_malloc(size_t _Size,size_t _Alignment);
> -#endif
>
>_CRTIMP void *__cdecl _aligned_offset_malloc(size_t _Size,size_t
> _Alignment,size_t _Offset);
>_CRTIMP void *__cdecl _aligned_realloc(void *_Memory,size_t _Size,size_t
> _Alignment);
> @@ -90,6 +76,9 @@ void __mingw_aligned_free (void *_Memory);
>  void * __mingw_aligned_offset_realloc (void *_Memory, 

Re: [Mingw-w64-public] [PATCH] change GetThemeSysFont() to accept a LOGFONTW* parameter (bug #862)

[Ozkan Sezer]

On 10/25/20, JonY via Mingw-w64-public
 wrote:
> On 10/24/20 9:36 PM, Ozkan Sezer wrote:
>> See: https://sourceforge.net/p/mingw-w64/bugs/862/
>>
>> The reported issue is analogous to GetThemeFont(), i.e. see:
>> https://sourceforge.net/p/mingw-w64/feature-requests/82/
>> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ac919255813c22aaad9de8b230216f0a8c39d115/
>>
>> I guess everyone wants the Vista+ version with LOGFONTW. Is the
>> following patch OK?
>>
>> diff --git a/mingw-w64-headers/include/uxtheme.h
>> b/mingw-w64-headers/include/uxtheme.h
>> index 6153986..d4f43c9 100644
>> --- a/mingw-w64-headers/include/uxtheme.h
>> +++ b/mingw-w64-headers/include/uxtheme.h
>> @@ -353,7 +353,7 @@ THEMEAPI_(COLORREF) GetThemeSysColor(HTHEME
>> hTheme,int iColorId);
>>   THEMEAPI_(HBRUSH) GetThemeSysColorBrush(HTHEME hTheme,int iColorId);
>>   THEMEAPI_(WINBOOL) GetThemeSysBool(HTHEME hTheme,int iBoolId);
>>   THEMEAPI_(int) GetThemeSysSize(HTHEME hTheme,int iSizeId);
>> -THEMEAPI GetThemeSysFont(HTHEME hTheme,int iFontId,LOGFONT *plf);
>> +THEMEAPI GetThemeSysFont(HTHEME hTheme,int iFontId,LOGFONTW *plf);
>>   THEMEAPI GetThemeSysString(HTHEME hTheme,int iStringId,LPWSTR
>> pszStringBuff,int cchMaxStringChars);
>>   THEMEAPI GetThemeSysInt(HTHEME hTheme,int iIntId,int *piValue);
>>   THEMEAPI_(WINBOOL) IsThemeActive();
>>
>
> Patch looks good to me.

Applied to master, and to branches down to v5.x.
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/12b5d1344c23c5fdba7fb2c771d0476c2220db16/


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] change GetThemeSysFont() to accept a LOGFONTW* parameter (bug #862)

[Ozkan Sezer]

See: https://sourceforge.net/p/mingw-w64/bugs/862/

The reported issue is analogous to GetThemeFont(), i.e. see:
https://sourceforge.net/p/mingw-w64/feature-requests/82/
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ac919255813c22aaad9de8b230216f0a8c39d115/

I guess everyone wants the Vista+ version with LOGFONTW. Is the
following patch OK?

diff --git a/mingw-w64-headers/include/uxtheme.h
b/mingw-w64-headers/include/uxtheme.h
index 6153986..d4f43c9 100644
--- a/mingw-w64-headers/include/uxtheme.h
+++ b/mingw-w64-headers/include/uxtheme.h
@@ -353,7 +353,7 @@ THEMEAPI_(COLORREF) GetThemeSysColor(HTHEME
hTheme,int iColorId);
 THEMEAPI_(HBRUSH) GetThemeSysColorBrush(HTHEME hTheme,int iColorId);
 THEMEAPI_(WINBOOL) GetThemeSysBool(HTHEME hTheme,int iBoolId);
 THEMEAPI_(int) GetThemeSysSize(HTHEME hTheme,int iSizeId);
-THEMEAPI GetThemeSysFont(HTHEME hTheme,int iFontId,LOGFONT *plf);
+THEMEAPI GetThemeSysFont(HTHEME hTheme,int iFontId,LOGFONTW *plf);
 THEMEAPI GetThemeSysString(HTHEME hTheme,int iStringId,LPWSTR
pszStringBuff,int cchMaxStringChars);
 THEMEAPI GetThemeSysInt(HTHEME hTheme,int iIntId,int *piValue);
 THEMEAPI_(WINBOOL) IsThemeActive();

--
O.S


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] headers/ddraw.h: Add missing dwFlags of DD_BLTDATA struct.

[Ozkan Sezer]

I just pushed this 20 mins ago or so.
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/f86c5060ad8f2300271df204c24f017e1744a194/


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend

[Ozkan Sezer]

On 11/21/18, Edward Diener  wrote:
[...]
> Unfortunately this did not solve the problem using clang-7.0 with the
> gcc-8.1 backend. Most probably clang is using its own linker, rather
> than the mingw-64/gcc linker, and this is causing the problem. In
> clang-6.0 everything works properly.

OK, maybe other here might be able to help.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend

[Ozkan Sezer]

On 11/21/18, Edward Diener  wrote:
> On 11/20/2018 11:55 PM, Ozkan Sezer wrote:
>> On 11/21/18, Edward Diener
>>  wrote:
>>> On 11/20/2018 10:50 PM, Ozkan Sezer wrote:
>>>> On 11/21/18, Edward Diener
>>>>  wrote:
>>>>> I am building an application using clang-7.0 targeting gcc with
>>>>> mingw-64/gcc-8.1 as the backend. The application shows no errors
>>>>> compiling or linking. When I try to debug the application I get the
>>>>> messages from within gdb:
>>>>>
>>>>> [New Thread 6432.0x1b38]
>>>>> Mingw-w64 runtime failure:
>>>>> Unknown pseudo relocation protocol version 65536
>>>>>
>>>>> When building/running the same application with just mingw-64/gcc-8.1
>>>>> everything works fine.
>>>>>
>>>>> I realize that this is a clang-7.0 problem and may well be that I can
>>>>> not use gcc-8.1 as my clang-7.0 backend for some reason. But I was
>>>>> wondering if anybody on the mingw-64/gcc side would have any idea what
>>>>> would cause the run-time error to occur ?
>>>>>
>>>>
>>>> This may be related:
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=23872
>>>>
>>>> If it is the case, you will need an updated binutils
>>>> (or manually edit your linker scripts.)
>>>
>>> Thanks for the help.
>>>
>>> How do I get an updated binutils for mingw.w64 ?
>>
>> Toolchain builders will need to adopt that change and post
>> new toolchains
>>
>>> Where is the linker script located in a mingw.w64 distro ?
>>
>> It is usually at //lib/ldscripts
>> E.g.: d:\mingw32\i686-w64-mingw32\lib\ldscripts
>> or d:\mingw64\x86_64-w64-mingw32\lib\ldscripts
>>
> For gcc-8.1 x64, let's say, there is an 'ldscripts' directory at
> \mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\lib\ldscripts.
>
> In that directory is a number of files starting with i386pe. and
> i386pep. and the comment for these are that they are linker scripts.
>
> Do I need to alter all of these or just the i386pe.x and i386pep.x files ?
>
> In each file is the line '. = ALIGN(__section_alignment__);' but I also
> occasionally see another '. = ALIGN(n);' line occasionally. So how do I
> modify the file(s) ?

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=73af69e74974eaa155eec89867e3ccc77ab39f6d

I think, in all of those scripts, you should find the line (there should
be only one instance of it):
__rt_psrelocs_start = .;

Insert the new alignment directive just before that line.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend

[Ozkan Sezer]

On 11/21/18, Edward Diener  wrote:
> On 11/20/2018 10:50 PM, Ozkan Sezer wrote:
>> On 11/21/18, Edward Diener  wrote:
>>> I am building an application using clang-7.0 targeting gcc with
>>> mingw-64/gcc-8.1 as the backend. The application shows no errors
>>> compiling or linking. When I try to debug the application I get the
>>> messages from within gdb:
>>>
>>> [New Thread 6432.0x1b38]
>>> Mingw-w64 runtime failure:
>>> Unknown pseudo relocation protocol version 65536
>>>
>>> When building/running the same application with just mingw-64/gcc-8.1
>>> everything works fine.
>>>
>>> I realize that this is a clang-7.0 problem and may well be that I can
>>> not use gcc-8.1 as my clang-7.0 backend for some reason. But I was
>>> wondering if anybody on the mingw-64/gcc side would have any idea what
>>> would cause the run-time error to occur ?
>>>
>>
>> This may be related:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=23872
>>
>> If it is the case, you will need an updated binutils
>> (or manually edit your linker scripts.)
>
> Thanks for the help.
>
> How do I get an updated binutils for mingw.w64 ?

Toolchain builders will need to adopt that change and post
new toolchains

> Where is the linker script located in a mingw.w64 distro ?

It is usually at //lib/ldscripts
E.g.: d:\mingw32\i686-w64-mingw32\lib\ldscripts
or  d:\mingw32\x86_64-w64-mingw32\lib\ldscripts


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend

[Ozkan Sezer]

On 11/21/18, Edward Diener  wrote:
> I am building an application using clang-7.0 targeting gcc with
> mingw-64/gcc-8.1 as the backend. The application shows no errors
> compiling or linking. When I try to debug the application I get the
> messages from within gdb:
>
> [New Thread 6432.0x1b38]
> Mingw-w64 runtime failure:
>Unknown pseudo relocation protocol version 65536
>
> When building/running the same application with just mingw-64/gcc-8.1
> everything works fine.
>
> I realize that this is a clang-7.0 problem and may well be that I can
> not use gcc-8.1 as my clang-7.0 backend for some reason. But I was
> wondering if anybody on the mingw-64/gcc side would have any idea what
> would cause the run-time error to occur ?
>

This may be related:
https://sourceware.org/bugzilla/show_bug.cgi?id=23872

If it is the case, you will need an updated binutils
(or manually edit your linker scripts.)


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Large file support?

[Ozkan Sezer]

On 3/6/18, Christer Solskogen  wrote:
> On 06.03.2018 14:13, JonY via Mingw-w64-public wrote:
>>
>> Or try recompiling with -D_POSIX=1 -D_FILE_OFFSET_BITS=64.
>
> Thanks, that worked!

Is _FILE_OFFSET_BITS is really tied to _POSIX?  IIRC, _POSIX had more
side effects which may or may not be wanted (or I may be wrong..)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Fix gendef fallthroughts and enable winpthreads library build

[Ozkan Sezer]

On 10/6/17, JonY via Mingw-w64-public
 wrote:
> Patches OK?

gendef fallthrough patch looks bogus to me.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Where are headers defined?

[Ozkan Sezer]

On 8/5/17, Jeroen Ooms  wrote:
> Trying to build opendap [1] but the configure script can't find uuid.h:
>
> checking uuid/uuid.h usability... no
> checking uuid/uuid.h presence... no
> checking for uuid/uuid.h... no
> checking uuid.h usability... no
> checking uuid.h presence... no
> checking for uuid.h... no
> configure: error: Could not find uuid.h
>
> I see mingw-w64 includes libuuid.a but no header is included? Are
> these headers part of some other file in mingw-w64?
>
>
> [1] https://www.opendap.org/index.php/software/libdap/3.18.1

libuuid.a from mingw has nothing to do with e2fsprogs which
provides uuid/uuid.h, or OSSP uuid which provides uuid.h.
mingw[-w64] provides neither.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] pdh.h: use PDH_FUNCTION for Vista+ functions

[Ozkan Sezer]

On 3/16/17, Liu Hao  wrote:
> On 2017/3/16 5:26, Jon Turney wrote:
>> Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are
>> correctly decorated with WINAPI (= stdcall on x86), so linkage works
>> correctly on x86.
> This is indeed how Microsoft people declare these functions. Is this
> patch ok to apply?

Looks OK to me.

> However, unlike other function declarations, each of which resides in a
> single line, each of these five declarations occupies multiple lines. I
> don't know whether we should fix that as well.

One thing at a time should be the preferable way to  make changes.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gendef updates in git, one configury issue

[Ozkan Sezer]

On 3/7/17, NightStrike <nightstr...@gmail.com> wrote:
> On Tue, Mar 7, 2017 at 11:38 AM, Ozkan Sezer <seze...@gmail.com> wrote:
[...]
>>> There is one configury issue I didn't touch: If I configure with
>>>  --with-mangle=/some/path switch, the library functions checks
>>> i.e. memset, strdup, strlwr and strrchr fail. config.log says that
>>> it cannot find -lmangle around those failures. Probably we need
>>> to add -L/some/path/lib to LDFLAGS before those checks, but
>>> I'd like to leave that to Nightstrike who used to handle those
>>> stuff (I guess he still does, yes?)
>>
>> Well, moving the --with-mangle checks to after all other checks
>> works fine: a patch is attached, Ok to apply?
>
> I don't quite understand why moving those header checks earlier makes
> it all work, but there's nothing inherently wrong with the patch, so
> go for it.
>

Applied to master and to branches.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gendef updates in git, one configury issue

[Ozkan Sezer]

On 3/7/17, Ozkan Sezer <seze...@gmail.com> wrote:
> Several gendef updates were pushed to the git repo, one to fix
> a use-after-free, one to sig a segfault (bug#592), one to fix an
> unbalanced #pragma pack, etc.
>
> There is one configury issue I didn't touch: If I configure with
>  --with-mangle=/some/path switch, the library functions checks
> i.e. memset, strdup, strlwr and strrchr fail. config.log says that
> it cannot find -lmangle around those failures. Probably we need
> to add -L/some/path/lib to LDFLAGS before those checks, but
> I'd like to leave that to Nightstrike who used to handle those
> stuff (I guess he still does, yes?)

Well, moving the --with-mangle checks to after all other checks
works fine: a patch is attached, Ok to apply?

--
O.S.
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] gendef updates in git, one configury issue

[Ozkan Sezer]

Several gendef updates were pushed to the git repo, one to fix
a use-after-free, one to sig a segfault (bug#592), one to fix an
unbalanced #pragma pack, etc.

There is one configury issue I didn't touch: If I configure with
 --with-mangle=/some/path switch, the library functions checks
i.e. memset, strdup, strlwr and strrchr fail. config.log says that
it cannot find -lmangle around those failures. Probably we need
to add -L/some/path/lib to LDFLAGS before those checks, but
I'd like to leave that to Nightstrike who used to handle those
stuff (I guess he still does, yes?)

--
O.S.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] liboleaut32.a: Fixed SetOaNoCache entry.

[Ozkan Sezer]

On 2/2/17, Jacek Caban  wrote:
> Please review.
>
> ---
>  mingw-w64-crt/lib32/oleaut32.def | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This looks correct.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Make build environment consistent

[Ozkan Sezer]

On 10/16/16, David Wohlferd  wrote:
[...]
> config.guess files downloaded from the current automake build tree.
>
> sezero has been checking in these beta versions, but no one seems to
> know why (and he hasn't responded to explain).

There are no beta or release versions of config.guess/config.sub, they
just are what they are. The ones included in automake-1.15 just happen
to be current at the time automake-1.15 was released. I usually update
them from git://git.sv.gnu.org/config.git in all my projects.

There is no immediate benefit or harm in [not] doing so, although when
cross-compiling on a weird platform, it is good to have the latest.

I have no objections if you or anyone else wants to replace them with
the ones from automake-1.15.

--
O.S.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Issues with vsscanf - first draft

[Ozkan Sezer]

On 7/8/16, dw <limegreenso...@yahoo.com> wrote:
> On 7/7/2016 4:06 PM, Ozkan Sezer wrote:
>> Two copies of this message arrived: the one from your yahoo
>> account is sent to spam folder by gmail and doesn't have the
>> patch. The one from your limegreensocks went properly into the
>> inbox and does have the patch.  Something to do with yahoo
>> perhaps?
>
> The one from yahoo went thru the Mingw-w64 mailing list.  The one from
> LimeGreenSocks.com (which was rejected by the list since it isn't a
> member) also had you on the To line.
>
> While I don't discount yahoo as a possible factor, I'm thinking the
> problem is the list.
>
> In any case, did you have a chance to look at the patch?
>

Unfortunately no. Kai would be the guy for reviewing asm stuff.

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Issues with vsscanf - first draft

[Ozkan Sezer]

On 7/8/16, dw <da...@limegreensocks.com> wrote:
> On 7/7/2016 6:45 AM, Ozkan Sezer wrote:
>> On 7/7/16, dw <limegreenso...@yahoo.com> wrote:
>>> I was looking to see if there was any more inline asm that could be
>>> removed from mingw-w64.  That brought me to vsscanf (and friends). This
>>> looked to be a messy bit of code that could probably use a review.
>>>
>>> As I started looking through it, I found what I believe to be a bunch of
>>> flaws (see
>>> https://codereview.stackexchange.com/questions/133266/turn-a-vsscanf-call-into-a-sscanf-call).
>>>
>>> I started trying to clean it up, but eventually decided that the only
>>> way to really make this 'clean' was to re-write it in pure assembly.
>>> Which I have done.
>>>
>>> I've got a first draft attached.  I don't know that this follows
>>> standard mingw-w64 coding conventions, but it follows Windows coding
>>> standards better than the existing code.
>>>
>>> My question is: Now what?
>>>
>>> The patch is written.  I've tested it and it looks like it works. Where
>>> do we go from here?
>>>
>>> Comments and advice are welcome.  Remember to regen Makefile.in if you
>>> want to build this.
>>>
>>> dw
>>>
>> There are no patches attached.
>
> Umm.  Hmm.  Looking in my 'Sent Items' there is.  But looking at the
> list archives, there isn't.
>
> I've attached it again, but since I'm not sure what went wrong the first
> time, I've also put it at http://www.limegreensocks.com/m6.patch (just
> in case).
>
> dw
>

Two copies of this message arrived: the one from your yahoo
account is sent to spam folder by gmail and doesn't have the
patch. The one from your limegreensocks went properly into the
inbox and does have the patch.  Something to do with yahoo
perhaps?

--
O.S.

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Issues with vsscanf - first draft

[Ozkan Sezer]

On 7/7/16, dw  wrote:
> I was looking to see if there was any more inline asm that could be
> removed from mingw-w64.  That brought me to vsscanf (and friends). This
> looked to be a messy bit of code that could probably use a review.
>
> As I started looking through it, I found what I believe to be a bunch of
> flaws (see
> https://codereview.stackexchange.com/questions/133266/turn-a-vsscanf-call-into-a-sscanf-call).
>
> I started trying to clean it up, but eventually decided that the only
> way to really make this 'clean' was to re-write it in pure assembly.
> Which I have done.
>
> I've got a first draft attached.  I don't know that this follows
> standard mingw-w64 coding conventions, but it follows Windows coding
> standards better than the existing code.
>
> My question is: Now what?
>
> The patch is written.  I've tested it and it looks like it works. Where
> do we go from here?
>
> Comments and advice are welcome.  Remember to regen Makefile.in if you
> want to build this.
>
> dw
>

There are no patches attached.

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Autotools & git

[Ozkan Sezer]

On 6/6/16, Hugo Beauzée-Luyssen  wrote:
> Hi,
>
> I'm wondering about the rational for having all autotools generated
> files commited to the git repository.
> Is there a specific reason for that? Or would it be OK to provide a
> patch that adds a bootstrap script for all project & removes the said
> generated files?
>

Not everyone would have the required autofoo installed on their
systems to generate the configury. To me, it is polite to have the
generated files as they are intended to be in the repo.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] intrin-impl.h and @cc

[Ozkan Sezer]

> Hi dw,
>
> patch is ok.  I assume that this feature can produce in some
> inline-assembler cases speed pretty well.  Additionally it avoid
> useless clobber of a register just to test one-time on flags.
>
> JonY, Jacek:  Could one of you commit this change?  thanks in advance.
>
> Thanks,
> Kai

I applied the patch to master.

--
O.S.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Contributing a package

[Ozkan Sezer]

On 5/26/15, Pavel Fedin p.fe...@samsung.com wrote:
  Hello!

 IMHO, no project is too small for a separate project page and repository.
 And I don't see how this could ever belong inside the mingw-w64 project,
 honestly, as it is not related to the Windows runtime in any way (unless
 I'm missing something, which is very well possible).

  Is mingw-w64 strictly limited to compiler and runtime only? I thought it's
 not, i've seen some ported packages in External binary packages ...

Back in the day (ca. 5 years ago) when mingw-w64 was newly
gaining popularity, we (myself included) had uploaded some w64
binaries of some popular packages such as libogg, libmad or SDL,
but not any longer.  We can even delete many, if not all, of those..

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building winpthreads dll fails when building cross compiler

[Ozkan Sezer]

On 5/8/15, Kai Tietz ktiet...@googlemail.com wrote:
 Patch is ok. Could someone please apply.

 Thanks,
 Kai


Applied to master, cherry-pick'ed into v4.x and v3.x, and pushed.

--
O.S.


 2015-05-08 11:24 GMT+02:00 Luke Allardyce lukeallard...@gmail.com:
 It turns out the flag was specified incorrectly, libtool apparently
 requires compiler options to be prefixed with -Wc, the attached patch
 fixes the issue.

 On 8 May 2015 at 14:31, Luke Allardyce lukeallard...@gmail.com wrote:
 One of the commits for Makefile.am has

 winpthreads doesn't depend on libpthread.  We only needed it because
 gcc was trying to link it by default.  This is most likely a gcc bug.
 andoni on irc found a workaround.  The frontend has a -no-pthread
 switch to prevent this default linking.  winpthreads now uses that to
 link, and we can thusly remove the fake libpthread from the build
 entirely.

 On 8 May 2015 at 14:25, LRN lrn1...@gmail.com wrote:
 On 08.05.2015 8:13, Luke Allardyce wrote:
 When building winpthreads as part of a cross compiler I found that the
 dll won't compile as the -no-pthread flag isn't passed to gcc


 I remember something about giving gcc a fake pthread library to allow
 earlier
 stage to be built. Can't say anything definitive right now, as i don't
 have
 access to my gcc-building machine.

 --
 O ascii ribbon - stop html email! - www.asciiribbon.org

 --
 One dashboard for servers and applications across
 Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable
 Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs

[Ozkan Sezer]

On 5/5/15, JonY jo...@users.sourceforge.net wrote:
 On 5/5/2015 03:47, Alon Bar-Lev wrote:
 this somewhat reduces the error checking, but makes code and usage nicer.

 Hi,

 Thanks for the patch, but I'm rather ambivalent about keeping the
 top-level configure.

 It doesn't quite work as it is supposed to, building everything in one
 shot, since the CRT depend on an already installed header set before it
 can even compile. Likewise for the libraries.

 Kai? Ozkan? LRN? Any thoughts?


Personally, I like doing things stepwise + manually, so my vote would be no.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patch for bug 362

[Ozkan Sezer]

On 4/8/15, Kai Tietz ktiet...@googlemail.com wrote:
 Patch looks good to me.

 Kai


Applied the patch to master and cherry-picked into all stable
branches i.e. v4.x, v3.x, v2.x and v1.x

JohnD:  That part of the code seems originated from mingw.org
project, so you may want to notify them too.

--
O.S.

 2015-04-06 15:47 GMT+02:00 JohnD john.david.donog...@gmail.com:
 Hi,

 I've been looking at the mingw-w64 sources in regards to bug #362 [1]
 which
 has been reported indirectly recently as an issue on the octave bug
 tracker
 [2].

 I have attached a patch for mingw-w64 that fixes the issue for me.

 Let me know if there is anything I can do to get the patch  accepted.

 Thanks,

  JohnD

 [1] http://sourceforge.net/p/mingw-w64/bugs/362/
 [2] https://savannah.gnu.org/bugs/?44709



--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] v1.0.10 and v2.0.10 maintenance releases

[Ozkan Sezer]

mingw-w64 v1.0.10 and v2.0.10 are released for maintenance to fix
some recently revealed bugs, especially bug #465.  If anyone is
still using v1.x or v2.x series, they should update.


v1.0.10 --
http://sf.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v1.0.10.tar.gz/download
Changes since v1.0.9 include:

- fixed a wrong operand size bug in longjmp() for x64 which
  would have led to crashes (bug #465)
- fixed vfwscanf() for x64
- fixed pseudo-reloc startup performance
- dwmapi.h: fixed structures packing (bug #419)
- winuser.h: fixed WM_TOUCH macro (bug #460)
- winuser.h: fixed a misplaced #endif which caused problems
  e.g. when NOGDI is defined (bug #397)
- winldap.h: fixed _cdecl calling convention typo (bug #458)
- several other header updates/fixes.


v2.0.10 --
http://sf.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v2.0.10.tar.gz/download
Changes since v2.0.9 include:

- fixed a wrong operand size bug in longjmp() for x64 which
  would have led to crashes (bug #465)
- fixed vfwscanf() for x64
- fixed pseudo-reloc startup performance
- lib32/kernel32.def: fix linking TryAcquireSRWLockExclusive
  and TryAcquireSRWLockShared symbols
- math: correct return-value for sqrt(-0.0) case as -0.0 as
  decribed in C99
- dwmapi.h: fixed structures packing (bug #419)
- winuser.h: fixed WM_TOUCH macro (bug #460)
- winuser.h: fixed a misplaced #endif which caused problems
  e.g. when NOGDI is defined (bug #397)
- winldap.h: fixed _cdecl calling convention typo (bug #458)
- dwrite.h (DWRITE_TEXT_METRICS): add missing lineCount member
  (bug #463.)
- ws2bth.h: fixed structures packing
- http.h: multiple fixes
- ipsectypes.h: fix IPSEC_TRANSFORM_TYPE and IPSEC_CIPHER_TYPE
  enumerations
- several other header updates/fixes.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] backports for v4.x ?

[Ozkan Sezer]

The following three commits look like they are condidates
for cherry-pick'ing into v4.x.  Should we do it?

FOR v4.x: commit 7b41fe36c0be9a14bf1d82c74dfd00f20370e8d7
Author: Jacek Caban ja...@codeweavers.com
Date:   Fri Jan 30 11:16:50 2015 +0100
time.h: Ensure that _POSIX_THREAD_SAFE_FUNCTIONS is defined if we
declare *_r functions.

FOR v4.x: commit e737933796365143a607d7c4ba4e210da0ca4d05
Author: Yuta NAKAI nak5...@live.jp
Date:   Tue Feb 10 21:10:02 2015 +0900
time.h: Remove an underscore prefix for ctime_s.

FOR v4.x: commit 32db221f0a50f4f9c86ce94b3eeeb21d7e5048e9
Author: Kai Tietz ktiet...@googlemail.com
Date:   Fri Feb 27 13:02:59 2015 +0100
Make sure we define _GTHREAD_USE_MUTEX_INIT_FUNC as 1 for windows-pthread.
(MAYBE FOR v3.x too?)

--
O.S.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] backports for v4.x ?

[Ozkan Sezer]

On 3/18/15, Kai Tietz ktiet...@googlemail.com wrote:
 2015-03-18 15:50 GMT+01:00 Ozkan Sezer seze...@gmail.com:
 The following three commits look like they are condidates
 for cherry-pick'ing into v4.x.  Should we do it?

 FOR v4.x: commit 7b41fe36c0be9a14bf1d82c74dfd00f20370e8d7
 Author: Jacek Caban ja...@codeweavers.com
 Date:   Fri Jan 30 11:16:50 2015 +0100
 time.h: Ensure that _POSIX_THREAD_SAFE_FUNCTIONS is defined if we
 declare *_r functions.

 That variant makes sense for 4.x.  not for earlier versions IMO.

 FOR v4.x: commit e737933796365143a607d7c4ba4e210da0ca4d05
 Author: Yuta NAKAI nak5...@live.jp
 Date:   Tue Feb 10 21:10:02 2015 +0900
 time.h: Remove an underscore prefix for ctime_s.

 Yes.

 FOR v4.x: commit 32db221f0a50f4f9c86ce94b3eeeb21d7e5048e9
 Author: Kai Tietz ktiet...@googlemail.com
 Date:   Fri Feb 27 13:02:59 2015 +0100
 Make sure we define _GTHREAD_USE_MUTEX_INIT_FUNC as 1 for
 windows-pthread.
 (MAYBE FOR v3.x too?)

 As it is more a implicit gcc-fix, I say yes.

 Kai

Done and pushed.

--
O.S.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] completely lost building/linking DLLs

[Ozkan Sezer]

On 3/3/15, Earnie ear...@users.sourceforge.net wrote:
 -Original Message-
 From: David Macek [mailto:david.mace...@gmail.com]

 I think mingw should generally look for .a files (not .lib), specifically
 .dll.a. in case
 of DLL link stubs.


 Binutils will handle .lib as well as .dll libraries

*not* the x64 versions, only x86...  So you do need to create *.dll.a
for x64 dlls.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FPU control word on startup

[Ozkan Sezer]

On 11/12/14, Carl Kleffner cmkleff...@gmail.com wrote:
 Hi,

 during tests with my mingw builds variant mingw-w64-for-python
 https://bitbucket.org/carlkl/mingw-w64-for-python/downloads I stumpled
 upon a flaw in mingw-w64 FPU handling on startup. This is issued at
 mingw-w64 builds of numpy https://github.com/numpy/numpy/issues/5194 and
 test
 failures when building win32 binaries with mingw based on gcc 4.8
 https://github.com/numpy/numpy/issues/4909. The reason for this
 behaviour: CRT_fp10.o (part of libmingw32.a) sets the FPU control word to
 extended precision on startup as per default. This can be overwritten by
 additionally linking CRT_fp8.o, but this is documented elsewhere
 (floath.h). As far I can see, this behaviour in mingw-w64 inherits from the
 Mingw32 codebase, but I'm not sure.

 There seems to be a consense, that 027f should be the standard for setting
 the FPU control word. Otherwise it gets into your way, see i.e.  Random and
 unexpected EXCEPTION_FLT_DIVIDE_BY_ZERO and
 EXCEPTION_FLT_INVALID__OPERATION
 http://blogs.msdn.com/b/dougste/archive/2008/11/12/random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx

 Is there some code in mingw.w64 that depends on extended precision as a
 default value? Otherwise this should be fixed in the mingw-w64 codebase
 IMHO.

 Regards

 Carl

PING ?

--
O.S.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

[Ozkan Sezer]

On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
 If we define _POSIX_, then getpid (process.h) was hidden.
 Is it correct ?

 PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
 use _POSIX_ anymore.
 MSVC 2012/2013 guard getpid with !__STDC__.

I believe (but not necessarily correct about iıt) that MSVC's _POSIX
symbol is intended for diffrerent purposes, i.e. windows posix subsystem,
and I believe that we are doing a wrong thing with having those _POSIX
ifdefs in our headers..  Someone correct me if I'm wrong.

--
O.S.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

[Ozkan Sezer]

On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


 I have no idea, but be aware at least one reference in GCC showed up:
 https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

 But maybe that's there exactly because _POSIX is in the MinGW-w64
 headers...

I remember that they defined _POSIX only because mingw-w64 headers
required it for certain declarations

--
O.S.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

[Ozkan Sezer]

On 11/7/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix
 subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


 I have no idea, but be aware at least one reference in GCC showed up:
 https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

 But maybe that's there exactly because _POSIX is in the MinGW-w64
 headers...

 I remember that they defined _POSIX only because mingw-w64 headers
 required it for certain declarations

 Also, should we consider renaming _POSIX to _POSIX_SOURCE?


What I am saying is that those two have different meanings.
If we ever get rid of _POSIX we will possibly need to remove
certain stuff too. Things that currently are guarded by _POSIX
but should actually be guarded by _POSIX_SOURCE are there too
and they are another part of the story.

--
O.S.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

[Ozkan Sezer]

On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
 On Fri, Nov 7, 2014 at 7:51 PM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do
  not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix
 subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


 I have no idea, but be aware at least one reference in GCC showed up:
 https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

 But maybe that's there exactly because _POSIX is in the MinGW-w64
 headers...

 I remember that they defined _POSIX only because mingw-w64 headers
 required it for certain declarations

 Also, should we consider renaming _POSIX to _POSIX_SOURCE?


 What I am saying is that those two have different meanings.
 If we ever get rid of _POSIX we will possibly need to remove
 certain stuff too. Things that currently are guarded by _POSIX
 but should actually be guarded by _POSIX_SOURCE are there too
 and they are another part of the story.


 During port libressl to Windows, I feel very painful on such macros.
 I want to use _POSIX_C_SOURCE to replace _POSIX, _POSIX_,
 _POSIX_SOURCE in all headers.
 The first is normalization in _mingw.h.in:

 --- a/mingw-w64-headers/crt/_mingw.h.in
 +++ b/mingw-w64-headers/crt/_mingw.h.in
 @@ -7,6 +7,26 @@
  #ifndef _INC__MINGW_H
  #define _INC__MINGW_H

 +#if defined(_POSIX) || defined(_POSIX_) \
 +   || defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)  \
 +   || defined(_REENTRANT) || defined(_THREAD_SAFE) ||
 defined(_POSIX_THREAD_SAFE_FUNCTIONS)
 +
 +/* This has been superseded by _POSIX_C_SOURCE. */
 +#ifndef _POSIX_SOURCE
 +#define _POSIX_SOURCE 1
 +#endif
 +
 +/* Functions like wcscasecmp() and strnlen() were only added in
 POSIX.1-2008 */
 +#ifndef _POSIX_C_SOURCE
 +#define _POSIX_C_SOURCE 200809L
 +#endif
 +
 +#if (defined(_REENTRANT) || defined(_THREAD_SAFE)) 
 !defined(_POSIX_THREAD_SAFE_FUNCTIONS)
 +#define _POSIX_THREAD_SAFE_FUNCTIONS 200809L
 +#endif
 +
 +#endif
 +

 comments ?

I'd say that this is lazy and wrong.  IMO, doing it right way should be
changing the correct (only the correct) _POSIX guards to _POSIX_SOURCE
instead, and hope that the project requesting such features are actually
defining _POSIX_SOURCE. (you should possily also cover _GNU_SOURCE, etc)

--
O.S.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] netioapi.h inconsistence

[Ozkan Sezer]

On 10/25/14, Alexey Pavlov alex...@gmail.com wrote:
 Hi!

 Some users report about inconsistency in netioapi header. They have
 issues with using it on WinXP. See:

 https://github.com/Alexpux/MINGW-packages/issues/279

 Regards,
 Alexey.

Looked at glib-2.42.0 source, its configury has a check for
if_nametoindex (configure.ac line 1033), and gio/gsocket.c
line 1932 creates its function only if HAVE_IF_NAMETOINDEX is
not defined. It seems like the check doesn't seem to find
the function, despite the fact that the header has its prototype
and iphlpapi.def (both lib32 and lib64 versions) have the
symbol. Seeing config.log may help why configury fails finding
it.

--
O.S.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Remove some _POSIX guards

[Ozkan Sezer]

On 10/6/14, JonY jo...@users.sourceforge.net wrote:
 On 10/4/2014 18:38, JonY wrote:
 This should be the same as the strtok_r case, the following will now be
 exposed:
 localtime_r
 gmtime_r
 ctime_r
 asctime_r

 Patch OK?

 diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
 index 5ce5849..1b228d8 100644
 --- a/mingw-w64-headers/crt/time.h
 +++ b/mingw-w64-headers/crt/time.h
 @@ -169,7 +169,6 @@ char *__cdecl ctime(const time_t *_Time)
 __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
  struct tm *__cdecl gmtime(const time_t *_Time)
 __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
  struct tm *__cdecl localtime(const time_t *_Time)
 __MINGW_ATTRIB_DEPRECATED_SEC_WARN;

 -#ifdef _POSIX
  #ifdef __GNUC__ /* FIXME: Other compilers that these macros work with?
 */
  #ifndef localtime_r
  #define localtime_r(_Time, _Tm)({ struct tm *___tmp_tm =
  \
 @@ -215,7 +214,6 @@ struct tm *__cdecl localtime(const time_t *_Time)
 __MINGW_ATTRIB_DEPRECATED_SEC_
  #define ctime_r(_Time,_Str) (ctime ((_Time)) ? (strcpy((_Str),ctime
 ((_Time))),(_Str)) : 0)
  #endif
  #endif /* __GNUC__ */
 -#endif /* _POSIX */

  time_t __cdecl mktime(struct tm *_Tm);
  time_t __cdecl _mkgmtime(struct tm *_Tm);


 Ping, change OK?

To me, the guard removal is good

  Alternative, get a real implementation in mingwex?


...  which may (or may not) come later.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Release with changes from master?

[Ozkan Sezer]

On 9/28/14, JonY jo...@users.sourceforge.net wrote:
 On 9/28/2014 19:04, Marat Radchenko wrote:
 Are there any plans to make a release that includes `master` branch
 commits?

 More specifically, I am interested in b354505e:

 Author: Kai Tietz ktiet...@googlemail.com
 Date:   Thu Dec 5 10:06:07 2013 +

 Add winapi-family feature, added missing Windows 7 + 8 stuff,
 consolidate header


 git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@6392
 4407c894-4637-0410-b4f5-ada5f102cad1

 b354505e fixes the fact that MinGW-W64 hides MsgWaitForMultipleObjects
 behind #ifndef NOGDI [1].

 And until this bug is fixed, there are issues compiling git(1) with
 MinGW-W64.

 [1] http://sourceforge.net/p/mingw-w64/bugs/397/


 Done, backported all changes from master to v3.x for that particular
 header.

Bug #397 is the result of a very much misplaced endif. I fixed it
in v1.x branch by commit 0ebd53:
http://sf.net/p/mingw-w64/mingw-w64/ci/0ebd53611277c73458eae9189dca774ee9103d61/
and in v2.x by commit 86cd97:
http://sf.net/p/mingw-w64/mingw-w64/ci/86cd97e495cc920e6f90345c9effea83a5bbb13d/
The latter can also be cherry-picked into main v3.x branch without
any conflicts.

I see that you backported the winuser.h changes from master into a
new sf/v3.x branch. I guess that you will merge things back into
main v3.x later, so I am not touching winuser.h.

--
O.S.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] cherrypick request

[Ozkan Sezer]

On 9/21/14, André Hentschel n...@dawncrow.de wrote:
 Hi,
 someone should cherry-pick this into stable branches:
 997b3564e412f33dccb1cb4671ffdb10d3507cd2


Cherry-picked into v1.x, v2.x and v3.x, and pushed.

--
O.S.

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Some new APIs and extending hid-API (shared with ddk)

[Ozkan Sezer]

On 8/29/14, Kai Tietz ktiet...@googlemail.com wrote:
 /home/ktietz/out/0002-New-header-gpio.h.txt

 new Windows GUIDs ...

 /home/ktietz/out/0003-Update-shared-headers-for-DDK-for-winapi-family-check-.txt
 New file hidclass.h and  updated other hid*.h headers for
 winapi-family check and Win7/8 support

 /home/ktietz/out/0004-Add-monitor-configuration-API.txt
 New monitor-configuration-API


Whitespace changes make the diffs really difficult to read:  Can you
please (for future changesets) at least apply the whitespace changes
beforehand and generate diffs for real changes?


 Ok for apply?

 Regards,
 Kai


--
O.S.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _lrotl and _lrotr

[Ozkan Sezer]

On 7/26/14, dw limegreenso...@yahoo.com wrote:
 Well, since no one else has responded, what would you say to this
 (attached)?

 If you like, I can write up a detailed description about why I believe
 this is the way to go, but hopefully the comments and code speak for
 themselves.  This should give the correct definitions for 32bit, LP64
 and LLP64.

 If this is approved, someone else will have to commit it.  git is not my
 thing.

Kai and/or Jon should be approving or rejecting this.



 dw

 On 7/20/2014 2:18 AM, Ozkan Sezer wrote:
 Regarding gcc PR target/61662:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
 http://gcc.gnu.org/viewcvs/gcc?view=revisionsortby=daterevision=212826

 In our intrin.h (and stdlib.h), we are overriding the definitions
 from ia32intrin.h possibly the original definition from gcc used
 to be wrong with relation to _LLP64?  Even if that were the case,
 what we have is wrong because _lrotl and _lrotr accept and return
 unsigned long for both win32 _and_ win64, and for windows that is
 strictly 32 bits.  We need to fix this.

 --
 O.S.




--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bug#755448: fixed in mingw-w64 3.1.0-3

[Ozkan Sezer]

On 7/26/14, Stephen Kitt li...@sk2.org wrote:
 Hi Rafaël,

 On Sat, 26 Jul 2014 12:52:44 +0200, Rafaël Carré fun...@videolan.org
 wrote:
 On 07/21/14 23:21, Stephen Kitt wrote:
 * Merge upstream implementation of strtok_r, so it's available on
   Windows XP. Thanks to Gianluigi Tiesi for pointing out the
  problem,
   and to Jonathan Young for pointing out that he'd fixed it
  upstream.
   (Closes: #755448.)

 This change breaks VLC, as the strtok_r prototype is not available
 anymore.

 According to:
 http://anonscm.debian.org/gitweb/?p=collab-maint/mingw-w64.git;a=blobdiff;f=debian/patches/strtok_r.patch;h=95e4b5e974f19b5725ad3bd349ac74ec6b2d994d;hp=c4aa476dd10754657fe752ee1aeab9cfa4871a83;hb=8625b8bcfd8a66d92ddbb76391e25ddf9e077857;hpb=362f462455a593a5316c72fdf39dc6df342b3da5
 the prototype is only defined under the condition:
 #if defined (_SVID_SOURCE) || defined (_BSD_SOURCE) || (_POSIX_C_SOURCE
 = 1) || defined(_XOPEN_SOURCE) || defined (_POSIX_SOURCE)

 This condition perfectly matches the glibc strtok_r documentation (see
 http://man7.org/linux/man-pages/man3/strtok.3.html for example or your
 local
 glibc documentation). But POSIX doesn't specify any conditions (see
 http://pubs.opengroup.org/onlinepubs/009695399/functions/strtok.html for
 details).

 However autoconf defines neither of these, but only _GNU_SOURCE

 glibc's features.h defines all the above features if _GNU_SOURCE is
 defined,
 but mingw-w64 does not.

 I'm not sure it makes sense for mingw-w64 to support _GNU_SOURCE, because
 _GNU_SOURCE requests GNU extensions, which aren't available in the
 Microsoft
 runtime. (One could argue that this could be used to request GNU-compatible
 extensions provided by mingw-w64 of course...)

 I suggest removing the ifdef altogether, as strtok_r will always be
 available.

 Strictly speaking, VLC should define one of the relevant _SOURCE macros
 (beyond _GNU_SOURCE) to conform to the glibc documentation (on glibc
 platforms), and that would fix the problem as a side-effect on mingw-w64.
 But
 I agree with you, removing the ifdef in mingw-w64 should be fine and would
 also fix the problem...

My vote goes for removing the condition altogether and making
the prototype always available please.

--
O.S.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wrong packing in bluetooth struct

[Ozkan Sezer]

On 7/27/14, LRN lrn1...@gmail.com wrote:
[...]
 (2013-09-08 22:41:48) LRN: meanwhile - go ahead, fix ws2bth.h (add #pragma
 pack(push, 1), #pragma pack(pop))


 Apparently, i forgot to report this.


Seems like v3.x and trunk version of ws2bth.h already has byte-packing
via the pshpack1.h and poppack.h includes. The v2.x version does need
fixing; just did that, here:
http://sourceforge.net/p/mingw-w64/mingw-w64/ci/8790e7cb674793a31f023d8fd3d16f8ed8dbde4d/

--
O.S.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wrong packing in bluetooth struct

[Ozkan Sezer]

On 7/27/14, LRN lrn1...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 27.07.2014 1:49, Ozkan Sezer wrote:
 On 7/27/14, LRN lrn1...@gmail.com wrote: [...]
 (2013-09-08 22:41:48) LRN: meanwhile - go ahead, fix ws2bth.h (add
 #pragma pack(push, 1), #pragma pack(pop))


 Apparently, i forgot to report this.


 Seems like v3.x and trunk version of ws2bth.h already has byte-packing
 via
 the pshpack1.h and poppack.h includes. The v2.x version does need fixing;
 just did that, here:
 http://sourceforge.net/p/mingw-w64/mingw-w64/ci/8790e7cb674793a31f023d8fd3d16f8ed8dbde4d/


 2014-07-26 22:03:20 +0400  RyanGlScott:I'm having trouble running
 Bluetooth-related code on MinGW-w64. It does work on MSVC.
 http://lpaste.net/108193
 2014-07-26 22:04:16 +0400  RyanGlScott:bind() fails, giving me the 
 error
 code 10049 (WSAEADDRNOTAVAIL).
 2014-07-26 22:14:52 +0400  lh_mouse:   RyanGlScott, try #define 
 WIN_VER
 0x0601
 #define _WIN32_WINNT 0x0601
 2014-07-26 22:17:34 +0400  RyanGlScott:lh_mouse: That didn't seem to 
 fix
 it, although it warned that _WIN32_WINNT was redefined.
 2014-07-26 22:18:03 +0400  lh_mouse:   RyanGlScott, define them before
 #include'ing any headers.
 2014-07-26 22:18:19 +0400  RyanGlScott:lh_mouse: Oh, duh. Sorry, I'll 
 try
 again.
 2014-07-26 22:18:54 +0400  RyanGlScott:lh_mouse: Hm, no difference.
 2014-07-26 22:20:03 +0400  lh_mouse:   No need to apologize. Is it 
 the 42nd
 line that you get an error?
 2014-07-26 22:20:44 +0400  RyanGlScott:Yeah, the output is Binding
 failed, errno 10049
 2014-07-26 22:31:25 +0400  lh_mouse:   I don't know why. But I 
 suggest you
 dump the binary contents of SOCKADDR_BTH of the two programs and check
 whether they are the same.
 2014-07-26 22:31:49 +0400  RyanGlScott:lh_mouse: Good idea. I'll check
 that
 out.
 2014-07-26 22:47:55 +0400  RyanGlScott:What's the best way of doing a
 binary dump in Windows? objdump.exe -S isn't revealing much to me.
 2014-07-26 22:51:18 +0400  lh_mouse:   RyanGlScott, I meant the 
 contents of
 that SOCKADDR_BTH you defined in your code.
 2014-07-26 22:54:18 +0400  RyanGlScott:lh_mouse: I'm not sure what the
 best
 way of comparing them is. Should I just make a simpler program containing
 only the SOCKADDR_BTH parts of compare their objdumps?
 2014-07-26 23:11:15 +0400  lh_mouse:   RyanGlScott, unsigned char *p =
 blah;
 for(size_t i = 0; i  sizeof(blah); ++i){ printf(%02X , *(p++)); }
 2014-07-26 23:14:37 +0400  RyanGlScott:lh_mouse: Is blah 
 representing
 the SOCKADDR_BTH address? And is there a reason to make it an unsigned char
 pointer type?
 2014-07-26 23:17:58 +0400  lh_mouse:   It should be that address 
 variable
 defined on line 35 in your code.
 2014-07-26 23:18:27 +0400  lh_mouse:   Just print all bytes of it in 
 hex.
 2014-07-26 23:20:50 +0400  RyanGlScott:Alright, the for the MinGW-w64
 version: 20 00 2A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00
 2014-07-26 23:21:08 +0400  RyanGlScott:And for the MSVC version: 20 
 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF
 FF FF
 2014-07-26 23:23:54 +0400  RyanGlScott:Curiously, the 2A changes every
 time
 I run the MinGW-w64 version.
 2014-07-26 23:25:58 +0400  lh_mouse:   That doesn't matter, it is one 
 of the
 padding bytes after addressFamily.


Can you translate: does the commit on v2.x (or using v3.x branch) fix the
issue, or not?

--
O.S.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _lrotl and _lrotr

[Ozkan Sezer]

Regarding gcc PR target/61662:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
http://gcc.gnu.org/viewcvs/gcc?view=revisionsortby=daterevision=212826

In our intrin.h (and stdlib.h), we are overriding the definitions
from ia32intrin.h possibly the original definition from gcc used
to be wrong with relation to _LLP64?  Even if that were the case,
what we have is wrong because _lrotl and _lrotr accept and return
unsigned long for both win32 _and_ win64, and for windows that is
strictly 32 bits.  We need to fix this.

--
O.S.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] fix incorrect __USE_MINGW_ANSI_STDIO check in wchar.h and stdlib.h

[Ozkan Sezer]

On 6/29/14, Ozkan Sezer seze...@gmail.com wrote:
 The attached tiny patch fixes incorrect __USE_MINGW_ANSI_STDIO check in
 wchar.h and stdlib.h: The check must be against the value, not against
 the existence of the macro. (c.f. _mingw_print_push.h, etc. headers.)

 OK for trunk and v3.x?

 --
 O.S.

No one replied. Went ahead and applied this to trunk and v3.x.



 diff --git a/mingw-w64-headers/crt/stdlib.h
 b/mingw-w64-headers/crt/stdlib.h
 index 268ab84..e38d481 100644
 --- a/mingw-w64-headers/crt/stdlib.h
 +++ b/mingw-w64-headers/crt/stdlib.h
 @@ -9,7 +9,7 @@
  #include crtdefs.h
  #include limits.h

 -#if defined (__USE_MINGW_ANSI_STDIO)  !defined (__USE_MINGW_STRTOX)
 +#if defined (__USE_MINGW_ANSI_STDIO)  ((__USE_MINGW_ANSI_STDIO + 0)
 != 0)  !defined (__USE_MINGW_STRTOX)
  #define __USE_MINGW_STRTOX 1
  #endif

 diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
 index 0ba6131..3fbd17f 100644
 --- a/mingw-w64-headers/crt/wchar.h
 +++ b/mingw-w64-headers/crt/wchar.h
 @@ -9,7 +9,7 @@
  #include crtdefs.h
  #include _mingw_print_push.h

 -#if defined (__USE_MINGW_ANSI_STDIO)  !defined (__USE_MINGW_STRTOX)
 +#if defined (__USE_MINGW_ANSI_STDIO)  ((__USE_MINGW_ANSI_STDIO + 0)
 != 0)  !defined (__USE_MINGW_STRTOX)
  #define __USE_MINGW_STRTOX 1
  #endif

 @@ -775,7 +775,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n,
 const wchar_t *__format, __builti
float __cdecl __mingw_wcstof(const wchar_t * __restrict__ nptr,
 wchar_t ** __restrict__ endptr);
long double __cdecl __mingw_wcstold(const wchar_t * __restrict__,
 wchar_t ** __restrict__);

 -#if defined(__USE_MINGW_ANSI_STDIO)
 +#if __USE_MINGW_ANSI_STDIO
__mingw_ovr
double __cdecl wcstod(const wchar_t * __restrict__ _Str,wchar_t **
 __restrict__ _EndPtr){
  return __mingw_wcstod(_Str,_EndPtr);


--
O.S.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck#174;
Code Sight#153; - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] fix incorrect __USE_MINGW_ANSI_STDIO check in wchar.h and stdlib.h

[Ozkan Sezer]

The attached tiny patch fixes incorrect __USE_MINGW_ANSI_STDIO check in
wchar.h and stdlib.h: The check must be against the value, not against
the existence of the macro. (c.f. _mingw_print_push.h, etc. headers.)

OK for trunk and v3.x?

--
O.S.

diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 268ab84..e38d481 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -9,7 +9,7 @@
 #include crtdefs.h
 #include limits.h

-#if defined (__USE_MINGW_ANSI_STDIO)  !defined (__USE_MINGW_STRTOX)
+#if defined (__USE_MINGW_ANSI_STDIO)  ((__USE_MINGW_ANSI_STDIO + 0)
!= 0)  !defined (__USE_MINGW_STRTOX)
 #define __USE_MINGW_STRTOX 1
 #endif

diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 0ba6131..3fbd17f 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -9,7 +9,7 @@
 #include crtdefs.h
 #include _mingw_print_push.h

-#if defined (__USE_MINGW_ANSI_STDIO)  !defined (__USE_MINGW_STRTOX)
+#if defined (__USE_MINGW_ANSI_STDIO)  ((__USE_MINGW_ANSI_STDIO + 0)
!= 0)  !defined (__USE_MINGW_STRTOX)
 #define __USE_MINGW_STRTOX 1
 #endif

@@ -775,7 +775,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n,
const wchar_t *__format, __builti
   float __cdecl __mingw_wcstof(const wchar_t * __restrict__ nptr,
wchar_t ** __restrict__ endptr);
   long double __cdecl __mingw_wcstold(const wchar_t * __restrict__,
wchar_t ** __restrict__);

-#if defined(__USE_MINGW_ANSI_STDIO)
+#if __USE_MINGW_ANSI_STDIO
   __mingw_ovr
   double __cdecl wcstod(const wchar_t * __restrict__ _Str,wchar_t **
__restrict__ _EndPtr){
 return __mingw_wcstod(_Str,_EndPtr);
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 268ab84..e38d481 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -9,7 +9,7 @@
 #include crtdefs.h
 #include limits.h
 
-#if defined (__USE_MINGW_ANSI_STDIO)  !defined (__USE_MINGW_STRTOX)
+#if defined (__USE_MINGW_ANSI_STDIO)  ((__USE_MINGW_ANSI_STDIO + 0) != 0)  
!defined (__USE_MINGW_STRTOX)
 #define __USE_MINGW_STRTOX 1
 #endif
 
diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 0ba6131..3fbd17f 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -9,7 +9,7 @@
 #include crtdefs.h
 #include _mingw_print_push.h
 
-#if defined (__USE_MINGW_ANSI_STDIO)  !defined (__USE_MINGW_STRTOX)
+#if defined (__USE_MINGW_ANSI_STDIO)  ((__USE_MINGW_ANSI_STDIO + 0) != 0)  
!defined (__USE_MINGW_STRTOX)
 #define __USE_MINGW_STRTOX 1
 #endif
 
@@ -775,7 +775,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const 
wchar_t *__format, __builti
   float __cdecl __mingw_wcstof(const wchar_t * __restrict__ nptr, wchar_t ** 
__restrict__ endptr);
   long double __cdecl __mingw_wcstold(const wchar_t * __restrict__, wchar_t ** 
__restrict__);
 
-#if defined(__USE_MINGW_ANSI_STDIO)
+#if __USE_MINGW_ANSI_STDIO
   __mingw_ovr
   double __cdecl wcstod(const wchar_t * __restrict__ _Str,wchar_t ** 
__restrict__ _EndPtr){
 return __mingw_wcstod(_Str,_EndPtr);
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/5] netioapi.h: Use WINAPI call convention for PIPINTERFACE_CHANGE_CALLBACK

[Ozkan Sezer]

On 6/25/14, Martin Willi mar...@strongswan.org wrote:
 ---
  mingw-w64-headers/include/netioapi.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/mingw-w64-headers/include/netioapi.h
 b/mingw-w64-headers/include/netioapi.h
 index ac92a7f..95f7f99 100644
 --- a/mingw-w64-headers/include/netioapi.h
 +++ b/mingw-w64-headers/include/netioapi.h
 @@ -557,7 +557,7 @@ NETIOAPI_API GetUnicastIpAddressTable(
PMIB_UNICASTIPADDRESS_TABLE *Table
  );

 -typedef VOID (*PIPINTERFACE_CHANGE_CALLBACK) (
 +typedef VOID (WINAPI *PIPINTERFACE_CHANGE_CALLBACK) (
PVOID CallerContext, PMIB_IPINTERFACE_ROW Row,
MIB_NOTIFICATION_TYPE NotificationType
  );
 --
 1.9.1


This seems correct and needs applying to v2.x and v3.x too.

--

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 5/5] ipsectypes.h: Begin IPSEC_CIPHER_TYPE enumeration at 1

[Ozkan Sezer]

On 6/25/14, Martin Willi mar...@strongswan.org wrote:
 Compared to the original headers all values are off by one.
 ---
  mingw-w64-headers/include/ipsectypes.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/mingw-w64-headers/include/ipsectypes.h
 b/mingw-w64-headers/include/ipsectypes.h
 index 969a9b8..1eb4abe 100644
 --- a/mingw-w64-headers/include/ipsectypes.h
 +++ b/mingw-w64-headers/include/ipsectypes.h
 @@ -73,7 +73,7 @@ typedef enum IPSEC_AUTH_TYPE_ {
  } IPSEC_AUTH_TYPE;

  typedef enum IPSEC_CIPHER_TYPE_ {
 -  IPSEC_CIPHER_TYPE_DES,
 +  IPSEC_CIPHER_TYPE_DES = 1,
IPSEC_CIPHER_TYPE_3DES,
IPSEC_CIPHER_TYPE_AES_128,
IPSEC_CIPHER_TYPE_AES_192,
 --
 1.9.1


Seems correct and needs applying to v2.x and v3.x too.

--

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 4/5] ipsectypes.h: Begin IPSEC_TRANSFORM_TYPE enumeration at 1

[Ozkan Sezer]

On 6/25/14, Martin Willi mar...@strongswan.org wrote:
 Compared to the original headers all values are off by one.
 ---
  mingw-w64-headers/include/ipsectypes.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/mingw-w64-headers/include/ipsectypes.h
 b/mingw-w64-headers/include/ipsectypes.h
 index e01b47b..969a9b8 100644
 --- a/mingw-w64-headers/include/ipsectypes.h
 +++ b/mingw-w64-headers/include/ipsectypes.h
 @@ -54,7 +54,7 @@ typedef enum IPSEC_PFS_GROUP_ {
  } IPSEC_PFS_GROUP;

  typedef enum IPSEC_TRANSFORM_TYPE_ {
 -  IPSEC_TRANSFORM_AH,
 +  IPSEC_TRANSFORM_AH = 1,
IPSEC_TRANSFORM_ESP_AUTH,
IPSEC_TRANSFORM_ESP_CIPHER,
IPSEC_TRANSFORM_ESP_AUTH_AND_CIPHER,
 --
 1.9.1

Seems correct and needs applying to v2.x and v3.x too.

--

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 3/5] iketypes.h: Remove superfluous #endif

[Ozkan Sezer]

On 6/25/14, Martin Willi mar...@strongswan.org wrote:
 Balances the #ifdef definition and fixes preprocessing the header.
 ---
  mingw-w64-headers/include/iketypes.h | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/mingw-w64-headers/include/iketypes.h
 b/mingw-w64-headers/include/iketypes.h
 index 1abee3d..8a27ff3 100644
 --- a/mingw-w64-headers/include/iketypes.h
 +++ b/mingw-w64-headers/include/iketypes.h
 @@ -212,7 +212,6 @@ typedef struct IKEEXT_PRESHARED_KEY_AUTHENTICATION1__ {
  FWP_BYTE_BLOB presharedKey;
  UINT32 flags;
  } IKEEXT_PRESHARED_KEY_AUTHENTICATION1;
 -#endif

  typedef struct IKEEXT_CERTIFICATE_AUTHENTICATION0_ {
  IKEEXT_CERT_CONFIG_TYPE inboundConfigType;
 --
 1.9.1

Seems correct and needs applying to v3.x too.
The header is generated from its *.idl though, and the idl needs
fixing accordingly.

--

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/5] fwptypes.h: Remove FWPM_DISPLAY_DATA0 type defintion

[Ozkan Sezer]

On 6/25/14, Martin Willi mar...@strongswan.org wrote:
 As the prefix indicates, this type belongs to fwpmtypes.h, where it is
 aready
 defined.
 ---
  mingw-w64-headers/include/fwptypes.h | 5 -
  1 file changed, 5 deletions(-)

 diff --git a/mingw-w64-headers/include/fwptypes.h
 b/mingw-w64-headers/include/fwptypes.h
 index 36c8340..d495b67 100644
 --- a/mingw-w64-headers/include/fwptypes.h
 +++ b/mingw-w64-headers/include/fwptypes.h
 @@ -333,11 +333,6 @@ typedef struct FWP_CONDITION_VALUE0_ {
  } __C89_NAMELESSUNIONNAME;
  } FWP_CONDITION_VALUE0;

 -typedef struct FWPM_DISPLAY_DATA0_ {
 -wchar_t *name;
 -wchar_t *description;
 -} FWPM_DISPLAY_DATA0;
 -
  #endif /* WINAPI_PARTITION_DESKTOP. */
  /* Begin additional prototypes for all interfaces */

 --
 1.9.1

The typedef really is in both headers. If this is applied, needs applying
to v3.x too. But the header is generated from its *.idl, so the idl needs
changing accordingly too.

--

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fls API bug?

[Ozkan Sezer]

On 6/8/14, lh_mouse lh_mo...@126.com wrote:
 Dear all,
I have noticed today that FlsAlloc/GetValue/SetValue/Free APIs are not
 declared in MinGW-w64 headers if I define _WIN32_WINNT as 0x0502. According
 to Microsoft SDK documentation these APIs should be available since WIndows
 Server 2003. Is this a bug in MinGW-w64?


Yes: in v3.x and trunk, they are guarded by _WIN32_WINNT = 0x0600
which is wrong. v1.x and v2.x don't have that guarding, which is
correct.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bug: TlsGetValue is called after TlsFree when compiled with -static

[Ozkan Sezer]

On 11/11/13, Kai Tietz ktiet...@googlemail.com wrote:
 Hello Sergei,

 2013/11/11 Sergei Antonov sap...@gmail.com:
 Hello!
 I'm using Mingw-w64 3.0 release compiled with gcc-4.7.2. This is my test
 pogram:

 ===
 #include windows.h
 #include tchar.h

 struct S {
   S() {
 OutputDebugString(test ctor);
   }
   ~S() {
 OutputDebugString(test dtor);
   }
 };

 int APIENTRY _tWinMain(HINSTANCE hInstance,
  HINSTANCE hPrevInstance,
  LPTSTRlpCmdLine,
  int   nCmdShow) {
   static S s; // === this will have to be destroyed on program exit
   return 0;
 }
 ===

 Compilation command:
 x86_64-w64-mingw32-g++ -m32 -static test.cpp -o test.exe

 I test the resultant .exe using Dr. Memory - an analog of valgrind for
 Windows ( http://drmemory.org/ ). It finds an error:

 D:\Programs\DrMemory-Windows-1.6.0-2\bin\drmemory.exe -- D:\test.exe
 ~~Dr.M~~ Dr. Memory version 1.6.0
 ~~Dr.M~~ Running D:\test.exe
 ~~Dr.M~~
 ~~Dr.M~~ Error #1: UNADDRESSABLE ACCESS: reading 0x7efdde1c-0x7efdde20 4
 byte(s)
 ~~Dr.M~~ # 0 KERNELBASE.dll!TlsGetValue+0x17
   (0x75d53c24 KERNELBASE.dll+0x13c24)
 ~~Dr.M~~ # 1 __mingwthr_run_key_dtors.part.0
 [../crt/tlsthrd.c:108]
 ~~Dr.M~~ # 2 __mingw_TLScallback
 [../crt/tlsthrd.c:129]
 ~~Dr.M~~ # 3 ntdll.dll!RtlUlonglongByteSwap+0x7a8
   (0x77b4dc49 ntdll.dll+0x7dc49)
 ~~Dr.M~~ # 4 ntdll.dll!wcscspn +0x251
   (0x77b40a91 ntdll.dll+0x70a91)
 ~~Dr.M~~ # 5 ntdll.dll!RtlExitUserProcess  +0x73
   (0x77b1d5a4 ntdll.dll+0x4d5a4)
 ~~Dr.M~~ # 6 KERNEL32.dll!ExitProcess  +0x14
   (0x75a179c5 KERNEL32.dll+0x179c5)
 ~~Dr.M~~ # 7 msvcrt.dll!__crtExitProcess
 ~~Dr.M~~ # 8 msvcrt.dll!_cinit
 ~~Dr.M~~ # 9 msvcrt.dll!exit
 ~~Dr.M~~ #10 _fu0___set_invalid_parameter_handler
 [../crt/crtexe.c:335]
 ~~Dr.M~~ #11 KERNEL32.dll!BaseThreadInitThunk  +0x11
   (0x75a1336a KERNEL32.dll+0x1336a)
 ~~Dr.M~~ Note: @0:00:01.194 in thread 4132
 ~~Dr.M~~ Note: instruction: mov0x0e10(%eax,%ecx,4) - %eax
 ~~Dr.M~~
 ~~Dr.M~~ ERRORS FOUND:
 ~~Dr.M~~   1 unique, 1 total unaddressable access(es)

 This error only happens for .exe compiled with -static.
 The reason is that TlsGetValue is called for an index *after* it has
 already been freed with TlsFree. I verified this by patching out a
 call to TlsFree in the binary - no error happened for the patched
 binary.

 So this -static mode reverse sequence of operation has to be fixed.
 Unfortunately, I cannot provide a patch since I don't understand the
 code well enough.

 Hmm, this is indeed interesting.  The underlying issue is here that on
 program-shutdown the emulTLS-destruction code in libgcc is called
 before TLS-hooks are ...
 In our startup-code/runtime library-code we don't call TlsFree
 ourself.  So within the routine __mingwthr_run_key_dtors we try to get
 the key-value of the key_dtor_list for calling the destructor.

 Of interest is here one point.  Are we already asserting in call of
 mingwthr_run_key_dtors in __mingw_TLScallback by the reason-value of
 DLL_PROCESS_DETACH, or by DLL_THREAD_DETACH?

 It might be that the call for DLL_PROCESS_DETACH we shouldn't do, as
 before the thread should have already be detached ...  at least worth
 a try.

 Regards,
 Kai

What is the status of this issue?

--
O.S.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] setjmp/longjmp blues

[Ozkan Sezer]

On 7/30/13, Roland Schwingel roland.schwin...@onevision.com wrote:
 Hi...

 Presently I am migrating a big codebase from GCC 4.4.3 to 4.8.2 using
 the current trunk mingw-w64 crt and headers. I am using a self built
 toolchain with SEH for 64bit windows and sjlj on 32bit windows.

 Everything appears to be fine when compiling for 32bit. But I am/was
 facing some trouble when running ObjectiveC code on 64 bit windows when
 using ObjectiveC (GNUStep) exceptions.

 We are still using traditional ObjC exceptions.

 NS_DURING
   code which can throw an excpetion
 NS_HANDLER
   exception handling code
 NS_ENDHANDLER

 All these 3 NS_ constructs are macros wrapping around setjmp(). With
 resolved macros it looks like this:

 {NSHandler NSLocalHandler;
 _NSAddHandler(NSLocalHandler);
 if (!setjmp(NSLocalHandler.jumpState))
 {
 code which can throw an excpetion
 _NSRemoveHandler(NSLocalHandler);
 }
 else
 {
   NSException *localException = NSLocalHandler.exception
   exception handling code
 }
 }

 The exception is thrown always from within an instance of the
 NSException class, which code is located in the gnustep-base dll. There
 the longjmp(jumpState,1) is performed.

 With our version of gcc 4.4.3 (which Kai knows very well ;-)) everything
 is fine. Not so with gcc 4.8.2 in release mode (without symbols). Here
 the resulting binary crashes (most of the times) when an exception is
 raised (exactly when the longjmp() is performed).

 After nearly loosing all of my remaining hairs in the last 3 days I
 found a workaround. As far as I can see in setjmp.h setjmp()/longjmp()
 wraps around _setjmp(jmp_buf,__builtin_frame_adress(0)) and longjmp()
 from msvcrt.dll.

 When I use gcc's __builtin_setjmp() / __builtin_longjmp() instead of the
 msvcrt supplied versions it works again. Has anyone seen something mad
 like that before?

 Just 2 more informations:

 1.
 When I do a normal setjmp()/longjmp() combo manually inside of an ObjC
 method everything is fine too. Works as expected. I assume when I cross
 dll borders (setjmp() in one dll and longjmp() in another) something is
 going mad. I would like to understand what is going on here.

 2.
 When I dump out the jmp_buf supplied to setjmp() and look at it it looks
 perfectly ok. Frameadress/Rip are correct. Even all other registers look
 ok. jmp_buf is also not corrupted in between of setjmp() and longjmp().

 And only win64 bit is affected not 32bit. Presently I am compiling with
 optimization completely turned off and nearly no other gcc options
 enabled beside of -fno-omit-frame-pointer.

 Thanks for your help,

 Roland


What is the status of this issue?

--
O.S.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/1] Corrected lib32/d3d9.def file (against directx_Jun2010_redist.exe)

[Ozkan Sezer]

On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 Seems 3 imports were listed as C++ functions when they are plain C
 functions.

 The attached patch corrects this.

 Qt Creator 3.1.0-rc1 built with Qt-5.3.0-beta1 using Angleproject
 could not resolve dll imports without this change.

 Best regards,

 Ray.


According to wine (wine/dlls/d3d9/), Direct3DShaderValidatorCreate9
must be a stdcall like Direct3DShaderValidatorCreate9@0. According to
wine again, several other exports in the def file are wrong too, e.g.
stdcall funcs DebugSetMute@0, D3DPERF_EndEvent@0, D3DPERF_GetStatus@0,
D3DPERF_QueryRepeatFrame@0, some of whose prototypes are actually
available so easy to confirm. However PSGPError, PSGPSampleTexture,
and DebugSetLevel are unknown. Many of these are undocumented, btw.

--
O.S.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/1] Corrected lib32/d3d9.def file (against directx_Jun2010_redist.exe)

[Ozkan Sezer]

On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 Can someone with commit rights take care of this for us please?

 Best regards,

 Ray.

 On Sun, Apr 13, 2014 at 5:35 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2014-04-13 17:52 GMT+02:00 Ozkan Sezer seze...@gmail.com:
 On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 Seems 3 imports were listed as C++ functions when they are plain C
 functions.

 The attached patch corrects this.

 Qt Creator 3.1.0-rc1 built with Qt-5.3.0-beta1 using Angleproject
 could not resolve dll imports without this change.

 Best regards,

 Ray.


 According to wine (wine/dlls/d3d9/), Direct3DShaderValidatorCreate9
 must be a stdcall like Direct3DShaderValidatorCreate9@0. According to
 wine again, several other exports in the def file are wrong too, e.g.
 stdcall funcs DebugSetMute@0, D3DPERF_EndEvent@0, D3DPERF_GetStatus@0,
 D3DPERF_QueryRepeatFrame@0, some of whose prototypes are actually
 available so easy to confirm. However PSGPError, PSGPSampleTexture,
 and DebugSetLevel are unknown. Many of these are undocumented, btw.

 --
 O.S.

 Such .def file changes are preapproved. Please apply.

 Regards,
 Kai



Pushed these revisions to svn:

trunk: rev. 6566
stable/v3.x: rev. 6567 (direct merge of r6566)
stable/v1.x and v2.x: rev. 6568 (merge of r5111 and 6566)

--
O.S.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/1] Corrected lib32/d3d9.def file (against directx_Jun2010_redist.exe)

[Ozkan Sezer]

On 4/13/14, Alexpux alex...@gmail.com wrote:

 13 апр. 2014 г., в 22:44, Alexpux alex...@gmail.com написал(а):


 13 апр. 2014 г., в 22:39, Ozkan Sezer seze...@gmail.com написал(а):

 On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 Can someone with commit rights take care of this for us please?

 Best regards,

 Ray.

 On Sun, Apr 13, 2014 at 5:35 PM, Kai Tietz ktiet...@googlemail.com
 wrote:
 2014-04-13 17:52 GMT+02:00 Ozkan Sezer seze...@gmail.com:
 On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 Seems 3 imports were listed as C++ functions when they are plain C
 functions.

 The attached patch corrects this.

 Qt Creator 3.1.0-rc1 built with Qt-5.3.0-beta1 using Angleproject
 could not resolve dll imports without this change.

 Best regards,

 Ray.


 According to wine (wine/dlls/d3d9/), Direct3DShaderValidatorCreate9
 must be a stdcall like Direct3DShaderValidatorCreate9@0. According to
 wine again, several other exports in the def file are wrong too, e.g.
 stdcall funcs DebugSetMute@0, D3DPERF_EndEvent@0,
 D3DPERF_GetStatus@0,
 D3DPERF_QueryRepeatFrame@0, some of whose prototypes are actually
 available so easy to confirm. However PSGPError, PSGPSampleTexture,
 and DebugSetLevel are unknown. Many of these are undocumented, btw.

 --
 O.S.

 Such .def file changes are preapproved. Please apply.

 Regards,
 Kai



 Pushed these revisions to svn:

 trunk: rev. 6566
 stable/v3.x: rev. 6567 (direct merge of r6566)
 stable/v1.x and v2.x: rev. 6568 (merge of r5111 and 6566)

 I see you comment PSGPError and another function in d3d9.def. Maybe you
 need do it on 64-bit .def too?

 I create def file from c:\windows\SysWOW64\d3d9.dll
 http://pastebin.kde.org/p2apqxdii

 And commented functions present in library. Why you comment them?

For x86 they are most possibly __stdcall (WINAPI) and we don't know
their exact signatures, therefore it is best that we comment them out.

For x86_64, there is no __stdcall so they are fine as they are, that's
why I didn't comment them out in the x86_64 defs.

--
O.S.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] update DDK object types

[Ozkan Sezer]

On 1/10/14, Lars Munch l...@segv.dk wrote:
 According to http://msdn.microsoft.com/en-us/library/ff558679(VS.85).aspx
 the
 ObjectType parameter should be written as *SomeObjectType, hence the extern
 object types should be POBJECT_TYPE pointers in order to be compatible with
 the
 MS DDK.

 Add missing TmXYZ object types as well, these are already defined in
 lib64/ntoskrnl.def and lib32/ntoskrnl.def

Applied this to trunk and to all stable branches. Thanks.
Added Amine from r/os to CC list.

--
O.S.


diff --git a/mingw-w64-headers/ddk/include/ddk/wdm.h
b/mingw-w64-headers/ddk/include/ddk/wdm.h
index 4f63829..ffca1a8 100644
--- a/mingw-w64-headers/ddk/include/ddk/wdm.h
+++ b/mingw-w64-headers/ddk/include/ddk/wdm.h
@@ -7544,13 +7544,17 @@ typedef struct _OBJECT_NAME_INFORMATION {
 } OBJECT_NAME_INFORMATION, *POBJECT_NAME_INFORMATION;

 /* Exported object types */
-extern POBJECT_TYPE NTSYSAPI CmKeyObjectType;
-extern POBJECT_TYPE NTSYSAPI ExEventObjectType;
-extern POBJECT_TYPE NTSYSAPI ExSemaphoreObjectType;
-extern POBJECT_TYPE NTSYSAPI IoFileObjectType;
-extern POBJECT_TYPE NTSYSAPI PsThreadType;
-extern POBJECT_TYPE NTSYSAPI SeTokenObjectType;
-extern POBJECT_TYPE NTSYSAPI PsProcessType;
+extern POBJECT_TYPE NTSYSAPI *CmKeyObjectType;
+extern POBJECT_TYPE NTSYSAPI *ExEventObjectType;
+extern POBJECT_TYPE NTSYSAPI *ExSemaphoreObjectType;
+extern POBJECT_TYPE NTSYSAPI *IoFileObjectType;
+extern POBJECT_TYPE NTSYSAPI *PsThreadType;
+extern POBJECT_TYPE NTSYSAPI *SeTokenObjectType;
+extern POBJECT_TYPE NTSYSAPI *PsProcessType;
+extern POBJECT_TYPE NTSYSAPI *TmEnlistmentObjectType;
+extern POBJECT_TYPE NTSYSAPI *TmResourceManagerObjectType;
+extern POBJECT_TYPE NTSYSAPI *TmTransactionManagerObjectType;
+extern POBJECT_TYPE NTSYSAPI *TmTransactionObjectType;

 /**
  *   Process Manager Types*
-- 
1.8.5.2

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw-w64 v3.1.0 out!

[Ozkan Sezer]

On 1/9/14, JonY jo...@users.sourceforge.net wrote:
 Hi all,

 This is a minor bug fix release based on the v3 stable branch.

 The notable changes include some fixes for winpthreads deadlocking and a
 workaround for C/C++ linkage clash in crt/intrin.h.


Some pointers for v3.next:

- r6424 and possibly r6425 need merging back to v3.x
- possibly r6423 too?
- bug #374 needs to be taken care of and then merged back to v3.x
https://sourceforge.net/p/mingw-w64/bugs/374/

--
O.S.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Fix missing _DISK_GEOMETRY_EX in DDK

[Ozkan Sezer]

On Mon, Dec 30, 2013 at 1:14 AM, Lars Munch l...@segv.dk wrote:
 When using the DDK for vista or above the following warning occurs.

 /include/ddk/ntddk.h:4151:13: warning: 'struct _DISK_GEOMETRY_EX' declared
 inside parameter list

 This patch simply defines _DISK_GEOMETRY_EX similar to:
 http://doxygen.reactos.org/d2/d49/ntddk_8h_source.html
 ---
  mingw-w64-headers/ddk/include/ddk/ntddk.h | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/mingw-w64-headers/ddk/include/ddk/ntddk.h 
 b/mingw-w64-headers/ddk/include/ddk/ntddk.h
 index 0c5ffbb..6f5259d 100644
 --- a/mingw-w64-headers/ddk/include/ddk/ntddk.h
 +++ b/mingw-w64-headers/ddk/include/ddk/ntddk.h
 @@ -69,6 +69,7 @@ struct _LOADER_PARAMETER_BLOCK;
  struct _CREATE_DISK;
  struct _DRIVE_LAYOUT_INFORMATION_EX;
  struct _SET_PARTITION_INFORMATION_EX;
 +struct _DISK_GEOMETRY_EX;

  typedef struct _BUS_HANDLER *PBUS_HANDLER;
  typedef struct _DEVICE_HANDLER_OBJECT *PDEVICE_HANDLER_OBJECT;
 --
 1.8.5.2



Applied this to  bot trunk and to stable branches. Thanks.

--
O.S.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Syber Terrorist, please help!!

[Ozkan Sezer]

On 11/8/13, Incongruous incongru...@outlook.com wrote:
 Please help me, a terrorist group calling themselves Google has invaded my
 computer. Every time I run IE11 it displays the web page of this abusive
 organization. Is there a way that Microsoft could provide some sort of
 protection against this kind of threat? Is there a way to stop this
 organization's political power from terrorizing our work/home computers?

 Please Microsoft, you are our only hope.


Can someone please ban this guy?

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to search mailing list archives?

[Ozkan Sezer]

On 11/3/13, sampo-mi...@zxid.org sampo-mi...@zxid.org wrote:
 I have a bug to report regarding linking, but before reporting I would
 like to do my homework.

 How does one search in the archives of this mailing list?

 Neither

 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 nor

 http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-w64-public

 seems to offer usable search interface. The search box on top of page
 searches all of sourceforge which is too wide. It also does not appear
 that google finds this mailing list (or at least it does not rank
 very high). The search terms were illegal relocation.

 I checked the bug tracker (which at least has search interface) at

 http://sourceforge.net/p/mingw-w64/bugs/?source=navbar

 and did not find anything with those terms.

 Cheers,
 --Sampo


http://sourceforge.net/p/mingw-w64/mailman/

For every mingw-w64 mailing list, it gives a search link.

--
O.S.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Short read mystery

[Ozkan Sezer]

On 10/16/13, Edscott Wilson edscott.wilson.gar...@gmail.com wrote:
 I've been banging my head against the monitor for the past nine hours and
 narrowed a problem down to the following.
  I've found that for certain data, the read() function will return a short
 byte count.

 Take the following test file: http://xffm.org/test.dbh and compile and
 execute the following program:


 #include stdio.h
 #include stdlib.h
 #include sys/types.h
 #include sys/stat.h
 #include fcntl.h
 #include errno.h


 int main(int argc, char **argv){
 int fd = open(test.dbh,O_RDWR);

Try adding O_BINARY to the open() flags here.


 void *data = malloc(256);
 size_t bytes = read(fd, data, 256);
 printf(bytes read=%ld\n, (long)bytes);
 printf(errno=%s\n, strerror(errno));
 close(fd);
 FILE *f = fopen(test.dbh, r);
 bytes = fread(data, 1, 256, f);
 printf(bytes fread=%ld\n, (long)bytes);
 return 1;
 }


 This is the output of the above program compiled with mingw gcc:

 bytes read=255
 errno=No error
 bytes fread=256

 Which is wrong. I get the same broken result with both:
 gcc.exe (rev5, Built by MinGW-W64 project) 4.8.1
 and
 gcc.exe (GCC) 4.6.2 (from mingw-32)

 Linux, of course, reads the 256 bytes correctly.

 So there is something in the file which breaks the read on Windows.
 What could possibly be wrong?
  Is there some Windows trick you need apply to make read() work as it is
 intended?
  Or would it be a bug of the mingw gcc port?

 Any help is appreciated.


--
O.S.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-w64 v3.0.1

[Ozkan Sezer]

On 10/2/13, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 Hi,

 I just noticed there is an SVN tag for 3.0.1 but no tarball.

 Could one be uploaded please?

IIRC, its only difference is the change of state from alpha to stable,
none of the other commits to 3.x branch seemed in the 3.0.1 tag

--
O.S.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] tcl fails to build due to conflicting implementation of EXCEPTION_REGISTRATION structure

[Ozkan Sezer]

On 9/16/13, Jacek Caban ja...@codeweavers.com wrote:
 On 09/16/13 21:26, Erik van Pienbroek wrote:
 Any ideas on whether this should be fixed in mingw-w64?

 AFAICS it's not present in PSDK. It contains only
 EXCEPTION_REGISTRATION_RECORD, no EXCEPTION_REGISTRATION. It was added
 by Kai in patch:
 http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/a0b651de6dee90c04f445167d9867806017f03aa

 Kai, why was it added?

 Jacek


Not psdk but IIRC, it is actually part of crt.

--
O.S.

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public