Re: [Mingw-w64-public] [PATCH 09/11] crt: Add compatibility for __imp___argv for ucrtbase

2017-11-07 Thread Jacek Caban
Hi Martin, On 11/7/17 10:29 PM, Martin Storsjö wrote: Normally calling code should use the right version of headers, but the getopt implementation in libmingwex will have a hardcoded reference to __imp___argv. I think it would be better to add __p___argv (a trivial wrapper around __argv) to

Re: [Mingw-w64-public] [PATCH 00/11] More fixes for ucrtbase

2017-11-07 Thread Jacek Caban
Hi Martin, On 11/7/17 10:29 PM, Martin Storsjö wrote: I've tested our support for ucrtbase.dll a bit further by trying building a handful of libraries with it, and fixing the issues I run into. With these patches, I'm able to build among others Qt (tested with 5.7.1). That's good to hear. Gre

[Mingw-w64-public] [PATCH 04/11] headers: Restructure declarations of external variables like _argc

2017-11-07 Thread Martin Storsjö
This is in preparation for redefining these declarations for ucrtbase. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdlib.h | 117 ++--- 1 file changed, 62 insertions(+), 55 deletions(-) diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-head

[Mingw-w64-public] [PATCH 06/11] headers: Use the single argument version of setjmp for ucrtbase

2017-11-07 Thread Martin Storsjö
Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/setjmp.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/crt/setjmp.h b/mingw-w64-headers/crt/setjmp.h index 804d9af..db9ee7f 100644 --- a/mingw-w64-headers/crt/setjmp.h +++ b/mingw-w64-headers/crt/s

[Mingw-w64-public] [PATCH 00/11] More fixes for ucrtbase

2017-11-07 Thread Martin Storsjö
I've tested our support for ucrtbase.dll a bit further by trying building a handful of libraries with it, and fixing the issues I run into. With these patches, I'm able to build among others Qt (tested with 5.7.1). Some libraries have an issue where autoconf tries to detect whether e.g. snprintf o

[Mingw-w64-public] [PATCH 07/11] headers: Always map e.g. time to _time32 or _time64 for ucrtbase

2017-11-07 Thread Martin Storsjö
ucrtbase doesn't have any function named plain 'time'. Force these to be remapped to the inline form even if inlining otherwise wouldn't be done. Make sure that we don't keep any non-inline declaration, because otherwise a caller that tries to take the function address would end up referring to tha

[Mingw-w64-public] [PATCH 03/11] headers: Remove an incorrect declaration of "environ" when _POSIX_ is defined

2017-11-07 Thread Martin Storsjö
There is nothing in our crt parts, neither compat wrappers nor import libraries, that defines a variable named "environ" without a leading underscore. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdlib.h | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mingw-

[Mingw-w64-public] [PATCH 05/11] headers: Hook up __argc and similar external variables for ucrtbase

2017-11-07 Thread Martin Storsjö
Not all the variables that were listed seem to be exported from ucrtbase though. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdlib.h | 45 -- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw

[Mingw-w64-public] [PATCH 11/11] crt: Provide compat wrappers for the unprefixed "timezone" and "tzname"

2017-11-07 Thread Martin Storsjö
We can't redirect these to the function calls via defines, since "#define timezone" will break any code that uses e.g. "struct timezone". We can provide a replacement data member here, but it is only updated on init. Alternatively, we could just skip providing these when building with ucrtbase, b

[Mingw-w64-public] [PATCH 01/11] crt: Don't add extra timezone related exports to ucrtbase.def

2017-11-07 Thread Martin Storsjö
These common parts from msvcrt-common.def.in don't belong in ucrtbase.def. Mark longjmp as DATA on X86 only, since we provide a wrapped version in misc/mingw_getsp.S, but only on X86. Signed-off-by: Martin Storsjö --- mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++ mingw-w64-crt/lib-comm

[Mingw-w64-public] [PATCH 02/11] headers: Remove unnecessary ifdefs around __p_* functions

2017-11-07 Thread Martin Storsjö
These are available in all versions of msvcrt, also on x86_64. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdlib.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h index c2990cc..c09a458 100644 --- a/mingw-w64-heade

[Mingw-w64-public] [PATCH 09/11] crt: Add compatibility for __imp___argv for ucrtbase

2017-11-07 Thread Martin Storsjö
Normally calling code should use the right version of headers, but the getopt implementation in libmingwex will have a hardcoded reference to __imp___argv. This allows using getopt while linking to ucrtbase. Signed-off-by: Martin Storsjö --- mingw-w64-crt/crt/ucrtbase_compat.c | 3 +++ 1 file c

[Mingw-w64-public] [PATCH 10/11] headers: Provide timezone/dstbias/tzname/daylight for ucrtbase

2017-11-07 Thread Martin Storsjö
Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/time.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h index 3e989d5..ac9afe8 100644 --- a/mingw-w64-headers/crt/time.h +++ b/mingw-w64-headers/crt/time.h @@ -109,1

[Mingw-w64-public] [PATCH 08/11] headers: Redirect f{seek, tell}o{, 64} to fseek/ftell/_fseeki64/_ftelli64 for ucrtbase

2017-11-07 Thread Martin Storsjö
We don't want to call the normal fseeko/ftello wrappers in libmingwex in this case. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdio.h | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-heade

Re: [Mingw-w64-public] [PATCHv2 1/2] headers: Use ___mb_cur_max_func instead of __mb_cur_max

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Jacek Caban wrote: On 07.11.2017 13:48, Martin Storsjö wrote: This avoids having libmingwex refer to the dllimported data symbol from msvcrt.dll, easing linking to ucrtbase.dll which doesn't have it exported as a data symbol. ___mb_cur_max_func didn't exist in msvcrt.dll un

Re: [Mingw-w64-public] [PATCHv2 2/2] crt: Remove ucrtbase_compat workarounds for __mb_cur_max

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Jacek Caban wrote: On 07.11.2017 13:48, Martin Storsjö wrote: This simplifies the compat wrapper quite significantly, and the workarounds weren't sufficient in any case (the local __mb_cur_max value only was updated if the current module set the locale). Signed-off-by: Mart

Re: [Mingw-w64-public] [PATCH] ucrtbase: Fix linking to fwrite in libucrtbase.a

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Martin Storsjö wrote: On Mon, 6 Nov 2017, Martin Storsjö wrote: This was missed in the cleanup in 7cde6573c435830c75fd5d915444388c27aff1e0, when the wrapper in libmingwex was made unnecessary and removed. Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/ucrtbase

Re: [Mingw-w64-public] [PATCH] headers: Define _M_ARM64 just like MSVC does

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Patch is okay. Please go ahead ans commit. Pushed, thanks! // Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, S

Re: [Mingw-w64-public] [PATCHv3 3/3] headers: Fix the ucrtbase version of asprintf and vasprinf

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Martin Storsjö wrote: On Tue, 7 Nov 2017, Martin Storsjö wrote: Move the format attribute to the right spot, use unique variables in the asprintf function (previously there were two variables named ret), use properly reserved identifiers throughout both functions. Signed-o

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Shinchiro Shinchiro
On Wed, Nov 8, 2017 at 12:05 AM, Jacek Caban wrote: > That's interesting. Do you know which ones? > > BTW, widl crash is a bug in widl by definition - it should produce an > error if there is a problem with IDLs. However, if updating IDLs fixes > the problem, it should be good enough for now. > I

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Jacek Caban
On 07.11.2017 17:03, Shinchiro Shinchiro wrote: > Forgot to mention the compiler, widl actually is working fine. The > culprit is in some idl files which might be outdated which produce > segfault (in dxgi1_6.idl case) That's interesting. Do you know which ones? BTW, widl crash is a bug in widl b

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Shinchiro Shinchiro
Forgot to mention the compiler, widl actually is working fine. The culprit is in some idl files which might be outdated which produce segfault (in dxgi1_6.idl case) -- Check out the vibrant tech community on one of the worl

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Jacek Caban
On 07.11.2017 15:42, Liu Hao wrote: > On 2017/11/7 21:55, Jacek Caban wrote: >> On 07.11.2017 14:42, Shinchiro Shinchiro wrote: >> >>> There's bug in some mingw-w64's idls which give segfault with >>> widl which of course fixed in wine >> >> Yeah, importing widl is a different topic. In the past, I

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Liu Hao
On 2017/11/7 21:55, Jacek Caban wrote: On 07.11.2017 14:42, Shinchiro Shinchiro wrote: At the moment, only directx idl is imported from wine. I want to suggest you to import other IDLs from wine/include too if it doesn't break anything. That's not really true, there are some other IDLs. I occa

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Shinchiro Shinchiro
Jacek Caban wrote: > > If you think there are more that should be imported, we could do it. > How about all IDL's from wine/include? As some idl depends on other idls, > it might be good choice to import all idls from it to avoid problem. Also, > this fix the segfault problem I'm having when gener

Re: [Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Jacek Caban
On 07.11.2017 14:42, Shinchiro Shinchiro wrote: > At the moment, only directx idl is imported from wine. I want to suggest > you to import other IDLs from wine/include too if it doesn't break > anything. That's not really true, there are some other IDLs. I occasionally import some more. If you thi

[Mingw-w64-public] Importing other IDLs from wine

2017-11-07 Thread Shinchiro Shinchiro
At the moment, only directx idl is imported from wine. I want to suggest you to import other IDLs from wine/include too if it doesn't break anything. There's bug in some mingw-w64's idls which give segfault with widl which of course fixed in wine

Re: [Mingw-w64-public] [PATCHv2 2/2] crt: Remove ucrtbase_compat workarounds for __mb_cur_max

2017-11-07 Thread Jacek Caban
On 07.11.2017 13:48, Martin Storsjö wrote: > This simplifies the compat wrapper quite significantly, and the > workarounds weren't sufficient in any case (the local __mb_cur_max > value only was updated if the current module set the locale). > > Signed-off-by: Martin Storsjö > --- > Reincluded set

Re: [Mingw-w64-public] [PATCHv2 1/2] headers: Use ___mb_cur_max_func instead of __mb_cur_max

2017-11-07 Thread Jacek Caban
On 07.11.2017 13:48, Martin Storsjö wrote: > This avoids having libmingwex refer to the dllimported data symbol > from msvcrt.dll, easing linking to ucrtbase.dll which doesn't have > it exported as a data symbol. > > ___mb_cur_max_func didn't exist in msvcrt.dll until Windows XP, > while __mb_cur_m

[Mingw-w64-public] [PATCHv2 2/2] crt: Remove ucrtbase_compat workarounds for __mb_cur_max

2017-11-07 Thread Martin Storsjö
This simplifies the compat wrapper quite significantly, and the workarounds weren't sufficient in any case (the local __mb_cur_max value only was updated if the current module set the locale). Signed-off-by: Martin Storsjö --- Reincluded setlocale and _wsetlocale in ucrtbase.def, which I missed i

[Mingw-w64-public] [PATCHv2 1/2] headers: Use ___mb_cur_max_func instead of __mb_cur_max

2017-11-07 Thread Martin Storsjö
This avoids having libmingwex refer to the dllimported data symbol from msvcrt.dll, easing linking to ucrtbase.dll which doesn't have it exported as a data symbol. ___mb_cur_max_func didn't exist in msvcrt.dll until Windows XP, while __mb_cur_max existed already in Windows 2000. Since we require a

Re: [Mingw-w64-public] [PATCH 1/3] headers: Use ___mb_cur_max_func instead of __mb_cur_max

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Martin Storsjö wrote: This avoids having libmingwex refer to the dllimported data symbol from msvcrt.dll, easing linking to ucrtbase.dll which doesn't have it exported as a data symbol. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/ctype.h | 2 +- mingw-w64-header

Re: [Mingw-w64-public] [PATCH] ucrtbase: Fix linking to fwrite in libucrtbase.a

2017-11-07 Thread Martin Storsjö
On Mon, 6 Nov 2017, Martin Storsjö wrote: This was missed in the cleanup in 7cde6573c435830c75fd5d915444388c27aff1e0, when the wrapper in libmingwex was made unnecessary and removed. Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/ucrtbase.def.in | 3 +-- 1 file changed, 1 insertion(

Re: [Mingw-w64-public] [PATCHv3 3/3] headers: Fix the ucrtbase version of asprintf and vasprinf

2017-11-07 Thread Martin Storsjö
On Tue, 7 Nov 2017, Martin Storsjö wrote: Move the format attribute to the right spot, use unique variables in the asprintf function (previously there were two variables named ret), use properly reserved identifiers throughout both functions. Signed-off-by: Martin Storsjö --- Now with __format

Re: [Mingw-w64-public] [PATCH 0/2] Top level build libraries/tools improvements

2017-11-07 Thread JonY via Mingw-w64-public
On 11/07/2017 04:47 AM, Alon Bar-Lev wrote: > On 7 November 2017 at 01:09, JonY via Mingw-w64-public > wrote: >> >> On 11/04/2017 09:02 PM, Alon Bar-Lev wrote: >>> Hi, >>> >>> I see that the patch to add winpthreads was finally merged, this is great as >>> we can patch less the build system at Gen