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
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
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(
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
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
35 matches
Mail list logo
