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

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.

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

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

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 GetModule

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

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 b57612d46f97ef

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

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

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

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: ht

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

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 branc

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

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-asynchrono

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

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 i

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

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 se

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

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 work

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

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 b

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

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 define

[Mingw-w64-public] (no subject)

> 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(__

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

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 segm

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

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 c

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

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 mima

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

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 issue

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

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 c

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

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

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

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

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

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

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

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

>> 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 > #i

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

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.)

[Mingw-w64-public] lrint on x64

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

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

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://lis

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

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

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

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.sour

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

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.) >>> >>>

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

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 membe

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

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 membe

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

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? &

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

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

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

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

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

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/ &

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

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+ ver

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

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-

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

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, may

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

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 a

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

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 >>>

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

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 >>>

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

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] > Mi

Re: [Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

On 11/1/18, Liu Hao wrote: > 在 2018/11/1 9:52, Mateusz 写道: >> During discussion about inttypes I realized that we check (in header >> files) if >> __USE_MINGW_ANSI_STDIO is active in non consistent way: >> #if defined(__USE_MINGW_ANSI_STDIO) && ((__USE_MINGW_ANSI_STDIO + 0) != >> 0) >> #elif defin

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

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

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

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

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

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

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

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 t

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

On 3/7/17, NightStrike wrote: > On Tue, Mar 7, 2017 at 11:38 AM, Ozkan Sezer 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

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

On 3/7/17, Ozkan Sezer 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-m

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

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,

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

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

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

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

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

On 7/8/16, dw 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 >&g

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

On 7/8/16, dw wrote: > On 7/7/2016 6:45 AM, Ozkan Sezer wrote: >> 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

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

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 b

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

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

Re: [Mingw-w64-public] [PATCH] crt: Add missing snprintf aliases

On 4/29/16, lh_mouse wrote: > snprintf() and _snprintf() are not equivalent. > > Given the following program: > ``` > #include > > int main(){ > char str[] = "0123456789"; > _snprintf(str, 5, "%s", "-"); > puts(str); > } > ``` > A standard-conforming program should write a n

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

> 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

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

On 5/26/15, Pavel Fedin 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,

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

On 5/8/15, Kai Tietz 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 : >> It turns out the flag was specified incorrectly, libtool apparently >> requires

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

On 5/5/15, JonY 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

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

On 4/8/15, Kai Tietz 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

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

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 Ch

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

On 3/18/15, Kai Tietz wrote: > 2015-03-18 15:50 GMT+01:00 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:

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

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 Date: Fri Jan 30 11:16:50 2015 +0100 time.h: Ensure that _POSIX_THREAD_SAFE_FUNCTIONS is defined if we declare

Re: [Mingw-w64-public] lrotl (final)

On 2/26/15, Kai Tietz wrote: > Hey dw, > > Thanks for the explanation. I wanted to be sure we have the reasoning > for this change explicit documented. So I have no more objections. > The patch is ok. Please go ahead. > > Thanks, > Kai Since no one else did, I applied the patch to both master

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

On 3/3/15, Earnie 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* th

Re: [Mingw-w64-public] Fix for problems with clang

On 1/19/15, Kai Tietz wrote: > Patch looks ok to me. > > Thanks, > Kai > Since no one else did, I applied and pushed this to master for dw. -- O.S. > 2015-01-18 0:48 GMT+01:00 dw : >> Re-sending since SF seems to have eaten the first one. >> >> A while back snow_xmas reported a problem compili

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

On 11/12/14, Carl Kleffner wrote: > Hi, > > during tests with my mingw builds variant mingw-w64-for-python > I stumpled > upon a flaw in mingw-w64 FPU handling on startup. This is issued at > mingw-w64 builds of numpy

Re: [Mingw-w64-public] getpid issue

On 11/7/14, Dongsheng Song wrote: > On Fri, Nov 7, 2014 at 7:51 PM, Ozkan Sezer wrote: >> On 11/7/14, Ray Donnelly wrote: >>> On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer wrote: >>>> On 11/7/14, Ruben Van Boxem wrote: >>>>> 2014-11-07 9:25 GM

Re: [Mingw-w64-public] getpid issue

On 11/7/14, Ray Donnelly wrote: > On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer wrote: >> On 11/7/14, Ruben Van Boxem wrote: >>> 2014-11-07 9:25 GMT+01:00 Ozkan Sezer : >>> >>>> On 11/7/14, Dongsheng Song wrote: >>>> > If we define _PO

Re: [Mingw-w64-public] getpid issue

On 11/7/14, Ruben Van Boxem wrote: > 2014-11-07 9:25 GMT+01:00 Ozkan Sezer : > >> On 11/7/14, Dongsheng Song wrote: >> > If we define _POSIX_, then getpid (process.h) was hidden. >> > Is it correct ? >> > >> > PS: MSVC 2012 is the last compi

Re: [Mingw-w64-public] getpid issue

On 11/7/14, Dongsheng Song 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 ab

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

On 10/25/14, Alexey Pavlov 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_name

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

On 10/6/14, JonY 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 >> inde

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

On 9/28/14, JonY 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 >> Date: Thu Dec 5 10:06:07 2013 + >> >> Add winapi-famil

Re: [Mingw-w64-public] cherrypick request

On 9/21/14, André Hentschel 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.

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

On 8/29/14, Kai Tietz 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/k

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

On 7/27/14, LRN wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 27.07.2014 1:49, Ozkan Sezer wrote: >> On 7/27/14, LRN wrote: [...] >>> (2013-09-08 22:41:48) LRN: meanwhile - go ahead, fix ws2bth.h (add >>> #pragma pack(push, 1), #pragma

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

On 7/27/14, LRN 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 includ

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

On 7/26/14, Stephen Kitt wrote: > Hi Rafaël, > > On Sat, 26 Jul 2014 12:52:44 +0200, Rafaël Carré > 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 >> >

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

d 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

[Mingw-w64-public] _lrotl and _lrotr

Regarding gcc PR target/61662: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662 http://gcc.gnu.org/viewcvs/gcc?view=revision&sortby=date&revision=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

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

On 6/29/14, Ozkan Sezer 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? &g

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

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-

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

On 6/25/14, Martin Willi 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

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

On 6/25/14, Martin Willi 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..

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

On 6/25/14, Martin Willi 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 >

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

On 6/25/14, Martin Willi 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 >

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

On 6/25/14, Martin Willi 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/net

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

On 6/8/14, lh_mouse 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 bu

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

On 7/30/13, Roland Schwingel 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 comp

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

On 11/11/13, Kai Tietz wrote: > Hello Sergei, > > 2013/11/11 Sergei Antonov : >> Hello! >> I'm using Mingw-w64 3.0 release compiled with gcc-4.7.2. This is my test >> pogram: >> >> === >> #include >> #include >> >> struct S { >> S() { >> OutputDebugStrin

Re: [Mingw-w64-public] [Poll] Move to git

On 5/9/14, JonY wrote: > Hi all, > > You may also use the other thread for further discussion, please keep > this thread for votes only. > > For mingw-w64 developers, state your SF ID; for the registered voters, > simply reply with the same email address you registered with. sezero [ ] Yes, move

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

On 4/13/14, Alexpux wrote: > > 13 апр. 2014 г., в 22:44, Alexpux написал(а): > >> >> 13 апр. 2014 г., в 22:39, Ozkan Sezer написал(а): >> >>> On 4/13/14, Ray Donnelly wrote: >>>> Can someone with commit rights take care of this for us please? >

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

On 4/13/14, Ray Donnelly 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 wrote: >> 2014-04-13 17:52 GMT+02:00 Ozkan Sezer : >>> On 4/13/14, Ray Donnelly wrote:

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

On 4/13/14, Ray Donnelly 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, > > R

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

On 1/10/14, Lars Munch 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 missin

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

On 1/9/14, JonY 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 merg

  1   2   3   4   5   6   7   >