Re: [Mingw-w64-public] [PATCH] dxgidebug.idl: import from wine

[Jacek Caban]

On 08.01.2020 06:46, Biswapriyo Nath wrote:

* This is required for VLC in msys2.
* This imports the idl file to the include directory instead of
direct-x because there is a pending patch to move direct-x idls to
include directory.
* This patch does not modify Makefile.in and aclocal.m4 files.



The patch looks good. I pushed both the patch moving headers and this one.


Thanks,

Jacek



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

[Mingw-w64-public] [PATCH] include: Move headers from direct-x/include/ to include/.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---

The history of separated dir predates my involvement in the project, so 
I can only guess original reasoning. Those days WindowsSDK includes and 
depends on DX headers, so keeping it as an optional "SDK" does not seem 
sensible. This patch moves files and does minimal makefile/configure 
change to support that. I will remove remaining build system bits as a 
follow up, if we agree on this one.


This cleans up and simplifies the code base.

There were a few duplicates between directories already. I kept 
direct-x/ dir versions of those (that's what ended up installed in my 
case before the change).


Please review.

Thanks,
Jacek


 mingw-w64-headers/Makefile.am |  63 +-
 mingw-w64-headers/configure.ac|   3 +-
 mingw-w64-headers/direct-x/include/audevcod.h |  44 -
 mingw-w64-headers/direct-x/include/mediaobj.h | 791 --
 .../direct-x/include/mediaobj.idl | 254 --
 .../{direct-x => }/include/_mingw_dxhelper.h  |   0
 .../{direct-x => }/include/amaudio.h  |   0
 .../{direct-x => }/include/amstream.h |   2 +-
 .../{direct-x => }/include/amstream.idl   |   0
 .../{direct-x => }/include/amvideo.h  |   2 +-
 .../{direct-x => }/include/amvideo.idl|   0
 mingw-w64-headers/include/audevcod.h  |  65 +-
 .../{direct-x => }/include/austream.h |   2 +-
 .../{direct-x => }/include/austream.idl   |   0
 .../{direct-x => }/include/d3d.h  |   0
 .../{direct-x => }/include/d3d10.h|   2 +-
 .../{direct-x => }/include/d3d10.idl  |   0
 .../{direct-x => }/include/d3d10_1.h  |   2 +-
 .../{direct-x => }/include/d3d10_1.idl|   0
 .../{direct-x => }/include/d3d10_1shader.h|   0
 .../{direct-x => }/include/d3d10effect.h  |   0
 .../{direct-x => }/include/d3d10misc.h|   0
 .../{direct-x => }/include/d3d10sdklayers.h   |   2 +-
 .../{direct-x => }/include/d3d10sdklayers.idl |   0
 .../{direct-x => }/include/d3d10shader.h  |   0
 .../{direct-x => }/include/d3d11.h|   2 +-
 .../{direct-x => }/include/d3d11.idl  |   0
 .../{direct-x => }/include/d3d11_1.h  |   2 +-
 .../{direct-x => }/include/d3d11_1.idl|   0
 .../{direct-x => }/include/d3d11_2.h  |   2 +-
 .../{direct-x => }/include/d3d11_2.idl|   0
 .../{direct-x => }/include/d3d11_3.h  |   2 +-
 .../{direct-x => }/include/d3d11_3.idl|   0
 .../{direct-x => }/include/d3d11_4.h  |   2 +-
 .../{direct-x => }/include/d3d11_4.idl|   0
 .../{direct-x => }/include/d3d11sdklayers.h   |   2 +-
 .../{direct-x => }/include/d3d11sdklayers.idl |   0
 .../{direct-x => }/include/d3d11shader.h  |   0
 .../{direct-x => }/include/d3d8.h |   0
 .../{direct-x => }/include/d3d8caps.h |   0
 .../{direct-x => }/include/d3d8types.h|   0
 .../{direct-x => }/include/d3d9.h |   0
 .../{direct-x => }/include/d3d9caps.h |   0
 .../{direct-x => }/include/d3d9types.h|   0
 .../{direct-x => }/include/d3dcaps.h  |   0
 .../{direct-x => }/include/d3dcommon.h|   2 +-
 .../{direct-x => }/include/d3dcommon.idl  |   0
 .../{direct-x => }/include/d3dcompiler.h  |   0
 .../{direct-x => }/include/d3dhal.h   |   0
 .../{direct-x => }/include/d3drm.h|   0
 .../{direct-x => }/include/d3drmdef.h |   0
 .../{direct-x => }/include/d3drmobj.h |   0
 .../{direct-x => }/include/d3dtypes.h |   0
 .../{direct-x => }/include/d3dvec.inl |   0
 .../{direct-x => }/include/d3dx9.h|   0
 .../{direct-x => }/include/d3dx9anim.h|   0
 .../{direct-x => }/include/d3dx9core.h|   0
 .../{direct-x => }/include/d3dx9effect.h  |   0
 .../{direct-x => }/include/d3dx9math.h|   0
 .../{direct-x => }/include/d3dx9math.inl  |   0
 .../{direct-x => }/include/d3dx9mesh.h|   0
 .../{direct-x => }/include/d3dx9shader.h  |   0
 .../{direct-x => }/include/d3dx9shape.h   |   0
 .../{direct-x => }/include/d3dx9tex.h |   0
 .../{direct-x => }/include/d3dx9xof.h |   0
 .../{direct-x => }/include/ddraw.h|   0
 .../{direct-x => }/include/ddrawi.h   |   0
 .../{direct-x => }/include/ddstream.h |   2 +-
 .../{direct-x => }/include/ddstream.idl   |   0
 .../{direct-x => }/include/dinput.h   |   0
 .../{direct-x => }/include/dls1.h |   0
 .../{direct-x => }/include/dls2.h |   0
 .../{direct-x => }/include/dmdls.h|   0
 .../{direct-x => }/include/dmerror.h  |   0
 .../{direct-x => }/include/dmo.h  |   0
 .../{direct-x => }/include/dmodshow.h  

Re: [Mingw-w64-public] Incorrect GUID definitions in mfidl.h

[Jacek Caban]

On 12/11/19 12:44 PM, Liu Hao wrote:

在 2019/12/10 19:17, Jacek Caban 写道:

On 12/10/19 12:10 PM, Liu Hao wrote:

You could just use make include/mfidl.h if you use configure with
--with-widl. This uses -DBOOL=WINBOOL when generating headers. IDL files
should use BOOL, not WINBOOL, and leave it for widl to generate correct
headers.



Thanks for the information. `-DBOOL=WINBOOL` makes WIDL compile the IDL
without any modification.

However `make include/mfidl.h` seemed to be stuck with some syntax
errors likes this:
```
crt/ctype.h:108: error: syntax error, unexpected aIDENTIFIER, expecting
tTYPEDEF
make[2]: *** [Makefile:1281: include/docobjectservice.h] Error 1
```



The attached patch should fix it, please review. It shouldn't be needed 
for include/mfidl.h through...



Jacek

commit 37c5be50b3549ed9695f45b509560b4338b813c2
Author: Jacek Caban 
Date:   Wed Dec 11 12:58:56 2019 +0100

mshtml.idl: Correctly import dxgitype.idl.

diff --git a/mingw-w64-headers/include/mshtml.idl b/mingw-w64-headers/include/mshtml.idl
index 3394f05d..1090fcba 100644
--- a/mingw-w64-headers/include/mshtml.idl
+++ b/mingw-w64-headers/include/mshtml.idl
@@ -83,7 +83,7 @@ interface IIE80DispatchEx : IDispatchEx {
 library MSHTML {
   importlib ("stdole2.tlb");
   import "ocidl.idl";
-  import "dxgitype.h";
+  import "dxgitype.idl";
 
   interface IDOMEvent;
   interface IElementBehavior;
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Incorrect GUID definitions in mfidl.h

[Jacek Caban]

On 12/10/19 12:10 PM, Liu Hao wrote:

在 2019/12/10 18:42, Eric Hassold 写道:

Hi all,

Tracking issue with one small program using Media Foundation was
failing at runtime only if compiled with Mingw, I found out that
definitions for some GUID in mfidl.h are incorrect (or mixed, with one
ID getting the value of another).

Namely, at mfidl.h:3407, GUID:
   MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE_VIDCAP_GUID
is defined as:
   0xc60ac5fe, 0x252a, 0x478f, 0xa0, 0xef, 0xbc, 0x8f, 0xa5, 0xf7, 0xca, 0xd3
but this is actually the UUID for MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE
(while definition for MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE itself is
missing).

Correct values should be:
EXTERN_GUID( MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE, 0xc60ac5fe, 0x252a,
0x478f, 0xa0, 0xef, 0xbc, 0x8f, 0xa5, 0xf7, 0xca, 0xd3);
EXTERN_GUID(MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE_VIDCAP_GUID,
0x8ac3587a, 0x4ae7, 0x42d8, 0x99, 0xe0, 0x0a, 0x60, 0x13, 0xee, 0xf9,
0x0f);

Attached is patch for mfidl.idl (need to regenerate mfidl.h, not
included in patch).



Thanks. Pushed this one.

Side note: WIDL 4.19 doesn't seem to like `WINBOOL` and reports syntax
errors likes this:
```
WIDL mediaobj.idl:20: error: syntax error, unexpected aIDENTIFIER
```

I replaced all `BOOL` with `WINBOOL` to generate the header. I also had
to be careful not to commit such changes by accident. I hope someone is
going to fix this issue.



You could just use make include/mfidl.h if you use configure with 
--with-widl. This uses -DBOOL=WINBOOL when generating headers. IDL files 
should use BOOL, not WINBOOL, and leave it for widl to generate correct 
headers.



Jacek



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

Re: [Mingw-w64-public] Generating new directx headers

[Jacek Caban]

Hi Zach,


On 08/12/2019 16:17, Zach Bacon wrote:

At this moment I'm looking at possibly including new directx headers namely 12, 
and I'm curious as to the process, would one begin with working on compatible 
headers first or the idl files?



Those are already present in Wine, we may just import it. See 
wine-import.sh.



Jacek



___
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] Header Additions

[Jacek Caban]

Hi Tom,

Patches look good, I pushed them.

Thanks,
Jacek

On 12/3/19 10:57 PM, Tom Ritter wrote:

Okay, the attached fixes that issue, I think this is ready now.

-tom

On Tue, 3 Dec 2019 at 12:46, Tom Ritter  wrote:

Hm. I haven't debugged this yet; but apparently something is still missing:


lld-link: error: undefined symbol: 
__Z14__mingw_uuidofI26IDCompositionDesktopDeviceERK5_GUIDv

(and more)

-tom

On Tue, 3 Dec 2019 at 04:59, Tom Ritter  wrote:

Attached is a correct patch (hopefully I didn't miss anything again...)

On Tue, 3 Dec 2019 at 04:26, Biswapriyo Nath  wrote:

In patch file:

1. File modes are changed to 755.
2. Extra spaces in typedefs at first, enums at last.


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


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




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

[Mingw-w64-public] [PATCH] wincrypt.h: Add missing CERT_CHAIN_* flags.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/include/wincrypt.h | 4 
 1 file changed, 4 insertions(+)


diff --git a/mingw-w64-headers/include/wincrypt.h b/mingw-w64-headers/include/wincrypt.h
index 7425823f..0e84a351 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -5006,6 +5006,10 @@ WINIMPM HCERTSTORE WINAPI CertOpenStore (LPCSTR lpszStoreProvider, DWORD dwEncod
 #define CERT_CHAIN_ENABLE_PEER_TRUST 0x400
 #define CERT_CHAIN_DISABLE_MY_PEER_TRUST 0x800
 #define CERT_CHAIN_DISABLE_MD2_MD4 0x1000
+#define CERT_CHAIN_DISABLE_AIA 0x2000
+#define CERT_CHAIN_HAS_MOTW 0x4000
+#define CERT_CHAIN_ONLY_ADDITIONAL_AND_AUTH_ROOT 0x8000
+#define CERT_CHAIN_OPT_IN_WEAK_SIGNATURE 0x1
 #define CERT_CHAIN_REVOCATION_CHECK_END_CERT 0x1000
 #define CERT_CHAIN_REVOCATION_CHECK_CHAIN 0x2000
 #define CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT 0x4000

___
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] include/netfw: add INetFwRule2 and INetFwRule3 interfaces

[Jacek Caban]

On 02/11/2019 15:46, Biswapriyo Nath wrote:


Thank you for the help. I've sent the patch in Wine devel mailing list. Two
questions:

1. If I want to improve a file which is in wine-import.sh shell script,
should I send patch twice -- one for mingw-w64 and one for wine-devel?



Sending to wine-devel is fine. It will be imported to mingw-w64 the next 
time I do imports. If there is a rush, for some reason, you may ping me 
or run the script yourself.




2. Why doesn't that wine-import.sh shell script conatin all header file
that mingw-w64 or wine has?


If both projects already have different versions of the same file, we 
can't just blindly replace one version with the other. They may not be 
compatible.



There is, however, a number of files that could be imported from Wine 
that are not present in mingw-w64. Those should be relatively easy to 
add to the script. The only reason it's not done yet is that no one did 
that so far.



Jacek



___
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] include/netfw: add INetFwRule2 and INetFwRule3 interfaces

[Jacek Caban]

On 03/11/2019 02:01, Liu Hao wrote:


在 2019/11/3 2:06, Jacek Caban 写道:

No, only if you touch files imported from Wine. See wine-import.sh
script if you're unsure if it's from Wine.



How do we know whether a specific header is imported from Wine or not?
By checking Git logs I presume?



Yes, git log or just looking at wine-import.sh script. Also LGPL license 
is a good hint, but it's not precise (eg. some files like dinput.h were 
imported from Wine without using the import script).



Jacek



___
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] include/netfw: add INetFwRule2 and INetFwRule3 interfaces

[Jacek Caban]

On 02/11/2019 10:08, Biswapriyo Nath wrote:


Apology for any mistake. I didn't know any upstream-downstream relationship
between wine and mingw-w64 repository. Some points:

* If there any improvement need for mingw-w64 should I **always** send a
patch to wine then mingw-w64?



No, only if you touch files imported from Wine. See wine-import.sh 
script if you're unsure if it's from Wine.




* Why don't wine or mingw-w64, one of them make other repsitory as a git
module? Will not it be more easy to maintain? Remember our previous wine
and mingw-w64 co-operation.



Making it a git module wouldn't really improve the workflow. Tightening 
projects closer could help with that and it was brought up earlier this 
year, but based on the feedback, it doesn't seem to be what community 
wants. We currently have a script-based import of a large chunk of Wine 
headers and widl. It's not perfect, but it's good enough so far. The 
thing about it is that once you modify a file on mingw-w64 side, those 
changes will be overwritten by the import script. This time I caught it 
and manually reverted that part.




* I am not familiar with how to send patch in wine. Once I want to
contribute to wine, one of my daydream :) but once I read the source code,
read the guidelines, chat with others, there are too many restrictions.



I really have no idea what are you talking about. Esp. if you change a 
header or IDL file, it's trivial to locate in the source code. Preparing 
a patch is identical to mingw-w64. You send it to wine-devel mailing 
list, just like you sent it to mingw-w64 mailing list. The process is 
identical except for git URL and mailing list address.




I copy all the code from Windows SDK to mingw-w64, does wine allow it?



Uh, I hope that you meant looking at Windows SDK while writing your 
patch. You're free to read it all you want, APIs are not copyrightable. 
Doing a blind copy is Windows SDK license violation and that's not 
welcomed in either project.




* Anyone can copy my patch to wine. No restriction.



Sure.


Jacek



___
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] include/netfw: add INetFwRule2 and INetFwRule3 interfaces

[Jacek Caban]

Hi Biswapriyo,


This patch is for a file imported from Wine. We have a script importing 
things from Wine and such changes would ideally go to Wine and be 
imported back to mingw-w64. Please consider upstreaming your changes to 
Wine. This was already committed to mingw-w64, so until they are in Wine 
and I can't use the import script for that file. I may need to 
eventually disable importing it, meaning that we will lose future Wine 
improvements.



It would be great if reviewers could pay more attention to such cases.


Thanks,

Jacek



___
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: Don't use __gnu_inline__ with __mingw_ovr in C++ mode

[Jacek Caban]

On 03/09/2019 08:39, Martin Storsjö wrote:


In C++ mode, __mingw_ovr is a plain "inline" without "static".

Clang emits a standalone copy of functions in C++ for the combination
of non-static inline and __gnu_inline__, leading to multiple definitions
of symbols.



I'm fine with this patch, but not so much about the fortify patch. 
Earlier this year we discussed inlines and if I remember right (sorry, I 
can't fine it now, maybe it was on IRC), the conclusion was to try to 
move toward static inline everywhere. Commit 
6988d73a95fbbd97a0bdbb517008cf18f4eb5f02 was a test to see if anything 
breaks. It seems fine so far, so I'd suggest to open code static inline 
for fortify wrappers instead of introducing a few new inline override 
macros.



Jacek



___
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: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

[Jacek Caban]

On 31/08/2019 23:08, Martin Storsjö wrote:

Apparently we were both mistaken with regard to this; even in the 
latest MSVC 2019, the default for wide stdio functions still is the 
legacy, C99 incompatible behaviour (where %s in a wide function means 
a wchar_t pointer).


And that makes the whole argument above moot; right now, the ucrt 
behaviour in mingw-w64 is different from both MSVC and mingw-w64 with 
msvcrt.dll.


Thus, resending a brushed up version of the old patch.



Oh, sorry about the misleading. I don't remember details about looking 
at it, but with those new facts, patches look good to me.



Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH] shobjidl.idl: added definition for FOS_SUPPORTSTREAMABLEITEMS to FILEOPENDIALOGOPTIONS enum

[Jacek Caban]

On 7/31/19 9:18 PM, Richard Pospesel wrote:

Signed-off-by: Richard Pospesel 
---
  mingw-w64-headers/include/shobjidl.h   | 8 +---
  mingw-w64-headers/include/shobjidl.idl | 3 ++-
  2 files changed, 7 insertions(+), 4 deletions(-)



I pushed the patch to git.


Thanks,

Jacek



___
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] shobjidl.idl: added definition for FOS_SUPPORTSTREAMABLEITEMS to FILEOPENDIALOGOPTIONS enum

[Jacek Caban]

On 01/08/2019 01:44, JonY via Mingw-w64-public wrote:


On 7/31/19 7:18 PM, Richard Pospesel wrote:

Signed-off-by: Richard Pospesel 
---
  mingw-w64-headers/include/shobjidl.h   | 8 +---
  mingw-w64-headers/include/shobjidl.idl | 3 ++-
  2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/mingw-w64-headers/include/shobjidl.h 
b/mingw-w64-headers/include/shobjidl.h
index 1bd1c0dc..108339eb 100644
--- a/mingw-w64-headers/include/shobjidl.h
+++ b/mingw-w64-headers/include/shobjidl.h
@@ -1,11 +1,12 @@
-/*** Autogenerated by WIDL 3.20 from include/shobjidl.idl - Do not edit ***/
+/*** Autogenerated by WIDL 4.5 from include/shobjidl.idl - Do not edit ***/
  
+#ifdef _WIN32

  #ifndef __REQUIRED_RPCNDR_H_VERSION__
  #define __REQUIRED_RPCNDR_H_VERSION__ 475
  #endif
-
  #include 
  #include 
+#endif

What is the reason for this change?



This is autogenerated part and that's an addition in recent IDL, not 
related to this patch.



The actual .idl change looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH] crt: Make a compat ___mb_cur_max_func on i386, to avoid forcing a dependency on XP

[Jacek Caban]

On 7/16/19 11:31 AM, Martin Storsjö wrote:

Before b1634783c20dbae, we never used ___mb_cur_max_func() (available in
msvcrt.dll since XP). Since that commit (done to unify things between
msvcrt and ucrt), any use of MB_CUR_MAX uses this function.

Therefore, make libmsvcrt-os.a for i386 provide this function statically,
using the __mb_cur_max data symbol, to restore compatibility as it was
before this commit.

Signed-off-by: Martin Storsjö 
---



The patch looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] MB_CUR_MAX breaks 2K/NT4 applications

[Jacek Caban]

On 7/16/19 8:52 AM, Martin Storsjö wrote:

On Mon, 15 Jul 2019, Gravis wrote:


So apparently, two years ago, someone decided to break all Windows
2K/NT4 applications that use MB_CUR_MAX.  See also:
https://sourceforge.net/p/mingw-w64/mailman/message/36107291/


As reasoned in the mail you quoted, it was my (and certainly others' 
as well) understanding that mingw-w64 generally requires at least XP, 
and that it is ok to assume XP, anywhere in the mingw-w64 code.



And the fact that it took two years for someone to notice suggests that 
the assumption is mostly right.




What I don't understand is why there isn't a simple "#if WINVER >=
0x0501" so that applications that are specifically built to run on
older systems can still run.


Why? Because it was everybody's expectation that we only needed to 
support XP.


Now, as noted on irc, these symbols are used in parts of lubmingwex, 
which is independent of version defines used in the calling code, and 
also is supposed to work with both msvcrt and ucrt, so an #if in the 
header would probably be brittle.


But it should be doable to wrap this function in the x86_32 import 
library, keeping the interface towards the crt import libraries 
uniform. I'll send a patch for this.


But the main question I see is, what's the project's policy wrt 
supporting older OS versions than the minimum (currently XP, but there 
have been discussions about raising it to Vista):


1) Require new code to be tested to still work with any older OS 
(essentially removing the minimum version concept altogether)


2) Disallow any workarounds for older versions

3) Allow reasonably non-intrusive workarounds, for things reported on 
the mailing list, but don't require people to test on versions prior 
to the minimum one (i.e. it can occasionally break and it's up to the 
users of said older versions to test and report) 



I think that the current 'status quo' solution is something like 3). I 
don't consider win2k as supported version (and at some point XP will be 
in similar position). In this case, Martin's patch fixing the problem is 
small and straightforward, so getting it committed sounds good.



That said, Gravis, your use case is extremely rare and expecting us to 
treat it with the same amount of care as we do for recent Windows 
version is unrealistic. If you use 20 years old OS, you may just as well 
use older version of mingw-w64. Another solution would be to start using 
msvcr90.dll (which is redistributable for win2k), which will probably 
work better in future mingw-w64 versions.



Jacek



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

Re: [Mingw-w64-public] Missing include in uuid.c

[Jacek Caban]

On 7/2/19 4:42 PM, Tom Ritter wrote:

The attached patch fixes an error from the recent commit for netlistmgr.h



Pushed.


Thanks,

Jacek



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

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Jacek Caban]

On 7/2/19 1:35 PM, LRN wrote:

On 02.07.2019 13:42, Jacek Caban wrote:

On 02/07/2019 12:38, LRN wrote:

On 02.07.2019 13:15, Jacek Caban wrote:

On 02/07/2019 12:12, Jacek Caban wrote:

On 02/07/2019 11:57, Liu Hao wrote:


在 2019/7/2 下午5:19, Eric Botcazou 写道:

It seems inappropriate to use handles as thread identifiers (as
handles
imply resource ownership and are not unique identifiers); thread
IDs (as
`DWORD` or `unsigned long`) would be a better alternative.

This was considered but ultimately rejected, as you can do nothing
with a
thread Id, i.e. you need a handle for everything.  But the
__gthread_equal
routine does compare the Ids and not the handles.


The `OpenThread()` function can obtain a handle by thread ID. It returns
a real handle that has to be closed when it is out of use. Using the
pseudo handle returned by `GetCurrentThread()` may be more efficient if
the target thread ID is equal to `GetCurrentThreadId()`.

The problem with thread id is that it's not valid nor guaranteed to be
identical after the thread is terminated. A handle needs to be used
for that.

I meant unique, not identical.


According to linux.die.net[0], Linux kernel re-uses thread IDs. This
stackoverflow answer[1] claims that this applies to all POSIX threads
implementations, citing opengroup spec[2].


It will not reuse them until you detach or join the thread. Joining may
happen after the thread is terminated.


It just means that you may not be able to use Windows thread IDs for that, but
using your own, homegrown thread IDs would be OK (just make sure an ID is valid
until a thread is joined or detached - that would usually imply keeping
metadata of a thread around after it's terminated).



That would be additional complication with additional problems. Without 
a handle, there is no reliable way to detect if thread is terminated and 
if it's not, you need to wait in join. Also, you'd replace handle leak 
to internal data leak.



Jacek



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

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Jacek Caban]

On 02/07/2019 12:38, LRN wrote:

On 02.07.2019 13:15, Jacek Caban wrote:

On 02/07/2019 12:12, Jacek Caban wrote:

On 02/07/2019 11:57, Liu Hao wrote:


在 2019/7/2 下午5:19, Eric Botcazou 写道:

It seems inappropriate to use handles as thread identifiers (as
handles
imply resource ownership and are not unique identifiers); thread
IDs (as
`DWORD` or `unsigned long`) would be a better alternative.

This was considered but ultimately rejected, as you can do nothing
with a
thread Id, i.e. you need a handle for everything.  But the
__gthread_equal
routine does compare the Ids and not the handles.


The `OpenThread()` function can obtain a handle by thread ID. It returns
a real handle that has to be closed when it is out of use. Using the
pseudo handle returned by `GetCurrentThread()` may be more efficient if
the target thread ID is equal to `GetCurrentThreadId()`.


The problem with thread id is that it's not valid nor guaranteed to be
identical after the thread is terminated. A handle needs to be used
for that.


I meant unique, not identical.


According to linux.die.net[0], Linux kernel re-uses thread IDs. This
stackoverflow answer[1] claims that this applies to all POSIX threads
implementations, citing opengroup spec[2].



It will not reuse them until you detach or join the thread. Joining may 
happen after the thread is terminated.



Jacek



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

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Jacek Caban]

On 02/07/2019 12:12, Jacek Caban wrote:

On 02/07/2019 11:57, Liu Hao wrote:


在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers (as 
handles
imply resource ownership and are not unique identifiers); thread 
IDs (as

`DWORD` or `unsigned long`) would be a better alternative.
This was considered but ultimately rejected, as you can do nothing 
with a
thread Id, i.e. you need a handle for everything.  But the 
__gthread_equal

routine does compare the Ids and not the handles.


The `OpenThread()` function can obtain a handle by thread ID. It returns
a real handle that has to be closed when it is out of use. Using the
pseudo handle returned by `GetCurrentThread()` may be more efficient if
the target thread ID is equal to `GetCurrentThreadId()`.



The problem with thread id is that it's not valid nor guaranteed to be 
identical after the thread is terminated. A handle needs to be used 
for that.



I meant unique, not identical.


Jacek



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

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Jacek Caban]

On 02/07/2019 11:57, Liu Hao wrote:


在 2019/7/2 下午5:19, Eric Botcazou 写道:

It seems inappropriate to use handles as thread identifiers (as handles
imply resource ownership and are not unique identifiers); thread IDs (as
`DWORD` or `unsigned long`) would be a better alternative.

This was considered but ultimately rejected, as you can do nothing with a
thread Id, i.e. you need a handle for everything.  But the __gthread_equal
routine does compare the Ids and not the handles.


The `OpenThread()` function can obtain a handle by thread ID. It returns
a real handle that has to be closed when it is out of use. Using the
pseudo handle returned by `GetCurrentThread()` may be more efficient if
the target thread ID is equal to `GetCurrentThreadId()`.



The problem with thread id is that it's not valid nor guaranteed to be 
identical after the thread is terminated. A handle needs to be used for 
that.



Jacek



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

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Jacek Caban]

Hi Eric,

On 6/28/19 3:42 PM, NightStrike wrote:

FYI, Eric posted this today to the GCC patches list.  This may be of
great interest to many who would prefer native threads instead of the
winpthreads posix style interface.

Great work, Eric!  I look forward to trying this out!

-- Forwarded message -
From: Eric Botcazou 
Date: Fri, Jun 28, 2019 at 6:51 AM
Subject: [patch] Reimplement GNU threads library on native Windows
To: 
Cc: 


Hi,

this reimplements the GNU threads library on native Windows (except for the
Objective-C specific subset) using direct Win32 API calls, in lieu of the
implementation based on semaphores.  This base implementations requires
Windows XP/Server 2003, which is the default minimal setting of MinGW-W64.
This also adds the support required for the C++11 threads, using again direct
Win32 API calls; this additional layer requires Windows Vista/Server 2008 and
is enabled only if _GTHREADS_USE_COND is defined to 1.

This also changes libstdc++ to setting _GTHREADS_USE_COND to 1 when the switch
--enable-libstdcxx-threads is passed, which means that C++11 threads are still
disabled by default on native Windows and that you need to explicitly pass the
switch to enable them.  The 30_threads chapter of the testsuite is clean.

Tested on i686-pc-mingw32 and x86_64-pc-mingw32, OK for the mainline?



It's indeed great to see this. Thank you!



+/* The implementation strategy for the c++0x thread support is as follows.
+
+   A GNU thread is represented by a Win32 HANDLE that is obtained when the
+   Win32 thread is created, except of course for the initial thread.  This
+   Win32 HANDLE is stored in a descriptor keyed from TLS memory for every
+   thread, so the self routine can return it instead of having to duplicate
+   the pseudo-handle returned by GetCurrentThread each time it is invoked.
+   For the initial thread, this Win32 HANDLE is created during the first
+   call to the self routine using the aforementioned technique.
+
+   Note that the equal routine compares the identifier of threads instead
+   of their Win32 HANDLE, which will give the correct positive answer even
+   in the case where distinct Win32 HANDLEs have been created for the same
+   thread by multiple instances of libgcc included in the link.  */


Note that this will cause handle leaks if used across multiple libgcc 
instances, through.


+#include "gthr-win32.h"
+
+/* The thread descriptor keyed from TLS memory.  */
+struct __gthr_win32_thr_desc
+{
+  void *(*func) (void*);
+  void *args;
+  HANDLE h;
+};
+
+/* The TLS key used by one instance of the library.  */
+static __gthread_key_t __gthr_win32_tls = TLS_OUT_OF_INDEXES;
+
+/* The initialization device for the TLS key.  */
+static __gthread_once_t __gthr_win32_tls_once = __GTHREAD_ONCE_INIT;
+
+/* Initialize the TLS key.  */
+
+static void
+__gthr_win32_tls_init (void)
+{
+  if (__gthread_key_create (&__gthr_win32_tls, free))
+abort ();
+}



You don't really need to store the whole __gthr_win32_thr_desc in TLS. If you 
stored just the handle, this wouldn't need a destructor.


Thanks,
Jacek



___
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] librpcrt4.a: Drop @0 suffix from varargs functions.

[Jacek Caban]

On 6/20/19 8:09 PM, Biswapriyo Nath wrote:

Can you add a little comment upon those changes? It may help future
contributions not to modify those and.



I'm not sure if there is a place to put them. If I added comments to 
rpcrt4 importlib, that won't help someone changing other DLLs. It would 
be great to have such things documented, through. I'm not aware of any 
good documentation of things interesting from mingw-w64 point of view 
like stdcall name mangling (or .def files in general).



Jacek



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

[Mingw-w64-public] [PATCH v2] librpcrt4.a: Drop @0 suffix from varargs functions.

[Jacek Caban]

Fixes a regression introduced by 047f934150cf5d14f7148ae12974c527a94bcca9

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/lib32/rpcrt4.def | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)


diff --git a/mingw-w64-crt/lib32/rpcrt4.def b/mingw-w64-crt/lib32/rpcrt4.def
index e8c73991..a494f08c 100644
--- a/mingw-w64-crt/lib32/rpcrt4.def
+++ b/mingw-w64-crt/lib32/rpcrt4.def
@@ -180,8 +180,8 @@ NDRSContextUnmarshall@8
 NDRSContextUnmarshallEx@12
 NDRcopy@12
 NdrAllocate@8
-NdrAsyncClientCall@0
-NdrAsyncClientCall2@0
+NdrAsyncClientCall
+NdrAsyncClientCall2
 NdrAsyncServerCall@4
 NdrByteCountPointerBufferSize@12
 NdrByteCountPointerFree@12
@@ -190,9 +190,9 @@ NdrByteCountPointerUnmarshall@16
 NdrCStdStubBuffer2_Release@8
 NdrCStdStubBuffer_Release@8
 NdrClearOutParameters@12
-NdrClientCall@0
-NdrClientCall2@0
-NdrClientCall4@0
+NdrClientCall
+NdrClientCall2
+NdrClientCall4
 NdrClientContextMarshall@12
 NdrClientContextUnmarshall@12
 NdrClientInitialize@16
@@ -239,8 +239,8 @@ NdrCorrelationFree@4
 NdrCorrelationInitialize@16
 NdrCorrelationPass@4
 NdrCreateServerInterfaceFromStub@8
-NdrDcomAsyncClientCall@0
-NdrDcomAsyncClientCall2@0
+NdrDcomAsyncClientCall
+NdrDcomAsyncClientCall2
 NdrDcomAsyncStubCall@16
 NdrDllCanUnloadNow@4
 NdrDllGetClassObject@24
@@ -284,9 +284,9 @@ NdrInterfacePointerMarshall@12
 NdrInterfacePointerMemorySize@8
 NdrInterfacePointerUnmarshall@16
 NdrMapCommAndFaultStatus@16
-NdrMesProcEncodeDecode@0
-NdrMesProcEncodeDecode2@0
-NdrMesProcEncodeDecode4@0
+NdrMesProcEncodeDecode
+NdrMesProcEncodeDecode2
+NdrMesProcEncodeDecode4
 NdrMesSimpleTypeAlignSize@4
 NdrMesSimpleTypeDecode@12
 NdrMesSimpleTypeEncode@16

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

[Mingw-w64-public] [PATCH] librpcrt4.a: Drop @0 suffix from varargs functions.

[Jacek Caban]

Fixes a regression introduced by 047f934150cf5d14f7148ae12974c527a94bcca9

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/lib32/rpcrt4.def | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)


diff --git a/mingw-w64-crt/lib32/rpcrt4.def b/mingw-w64-crt/lib32/rpcrt4.def
index e8c73991..80f3beee 100644
--- a/mingw-w64-crt/lib32/rpcrt4.def
+++ b/mingw-w64-crt/lib32/rpcrt4.def
@@ -181,7 +181,6 @@ NDRSContextUnmarshallEx@12
 NDRcopy@12
 NdrAllocate@8
 NdrAsyncClientCall@0
-NdrAsyncClientCall2@0
 NdrAsyncServerCall@4
 NdrByteCountPointerBufferSize@12
 NdrByteCountPointerFree@12
@@ -190,9 +189,8 @@ NdrByteCountPointerUnmarshall@16
 NdrCStdStubBuffer2_Release@8
 NdrCStdStubBuffer_Release@8
 NdrClearOutParameters@12
-NdrClientCall@0
-NdrClientCall2@0
-NdrClientCall4@0
+NdrClientCall
+NdrClientCall2
 NdrClientContextMarshall@12
 NdrClientContextUnmarshall@12
 NdrClientInitialize@16
@@ -240,7 +238,6 @@ NdrCorrelationInitialize@16
 NdrCorrelationPass@4
 NdrCreateServerInterfaceFromStub@8
 NdrDcomAsyncClientCall@0
-NdrDcomAsyncClientCall2@0
 NdrDcomAsyncStubCall@16
 NdrDllCanUnloadNow@4
 NdrDllGetClassObject@24
@@ -284,9 +281,8 @@ NdrInterfacePointerMarshall@12
 NdrInterfacePointerMemorySize@8
 NdrInterfacePointerUnmarshall@16
 NdrMapCommAndFaultStatus@16
-NdrMesProcEncodeDecode@0
-NdrMesProcEncodeDecode2@0
-NdrMesProcEncodeDecode4@0
+NdrMesProcEncodeDecode
+NdrMesProcEncodeDecode2
 NdrMesSimpleTypeAlignSize@4
 NdrMesSimpleTypeDecode@12
 NdrMesSimpleTypeEncode@16

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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 6/5/19 9:42 PM, Martin Storsjö wrote:

On Wed, 5 Jun 2019, Francois Gouget wrote:


3. Build a few projects - to make sure they build.

Wine, Wine Gecko, VLC should give a good coverage.


That sounds like long running tasks so we will likely need new 
hardware so the TestBot can run them for every patch that gets 
submitted: if patches come at a rate of about one per hour, then the 
TestBot needs to process the resulting jobs at a rate of at least one 
per hour. That said we already need new hardware for PCI-passthrough 
for Wine (though the exact details are not set yet).


Those projects are rather large, so either you need quite beefy 
hardware, or you just run some smaller test setup for each patch 
(rebuild mingw-w64 and build a few smoketests maybe?) and then run a 
full build of those projects e.g. nightly (e.g. with a known good 
pinned version of those projects, which can be updated regularly).



We don't have that many pushes, it shouldn't be too bad IMHO. For 
patches submitted manually, there could be checkboxes for tests you'd 
like to run, so could just skip tests if they don't need to be ran.



Jacek


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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 6/5/19 8:21 AM, Francois Gouget wrote:

3. Build a few projects - to make sure they build.

Wine, Wine Gecko, VLC should give a good coverage.

That sounds like long running tasks so we will likely need new hardware
so the TestBot can run them for every patch that gets submitted: if
patches come at a rate of about one per hour, then the TestBot needs to
process the resulting jobs at a rate of at least one per hour. That said
we already need new hardware for PCI-passthrough for Wine (though the
exact details are not set yet).



The rate of patches is much lower than one per hour. If tests would be 
ran on every git push, I'd say it's around 1/day on average, sometimes a 
few. I don't know how many manual submunitions there would be.



Thanks,

Jacek


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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 22/05/2019 21:45, Jacek Caban wrote:


- Testing

Wine has a TestBot and a number of test cases, which is a great tool 
for developers to make sure their patches are right. mingw-w64 does 
not have such thing and mostly depends on developers doing their own 
testing and regression reports after the patch is committed. We could 
integrate mingw-w64 testing with Wine TestBot to make sure that we 
don't break things (well, at least limit that possibility). I believe 
that it would nicely accelerate mingw-w64 development workflow as well 
as ensure that mingw-w64+Wine don't regress.



Here is how I imagine TestBot could look do:

1. Accept mingw-w64 patches (like it currently does for Wine patches)

2. Build a compiler toolchain

This is scripted in many places, so it shouldn't be too hard to 
automate. We could probably start with the most common configuration.


3. Build a few projects - to make sure they build.

Wine, Wine Gecko, VLC should give a good coverage.


Francois, how does that sound?


Ideally, mingw-w64 would have its own test suite that we could run here 
as well in addition to the above.



Thanks,

Jacek



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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 22/05/2019 21:45, Jacek Caban wrote:



- Source code sharing

Technically, we could share much more code than we currently do. 
Duplicating efforts is quite suboptimal for everyone. Right now 
mingw-w64 imports a number of platform headers and widl tool from Wine 
via wine-import.sh script. Wine has a few headers imported from 
mingw-w64 as well. It works to some extend, but the fact is that we 
still duplicate more than we share. I'm not yet sure how to fix that 
entirely, but I'd like us to have a workflow that would limit the 
duplication.



Let me split it by the region of code:


- Platform headers


We share quite a lot of those already by having changes go to Wine tree 
and being imported by a script. It's not pretty, but does the job. From 
the experience, there are minor things that often prevent using this for 
more headers. One of the most common is that Wine doesn't support 
version and family partitions guards in its headers. While they are 
useless for Wine, they are more important for mingw-w64 (especially 
family partitions). I guess that changing Wine policy should be easy and 
would help to share more.




- importlibs


Those are very different for both projects, keeping it separated makes 
probably more sense.




- CRT headers + msvcrt importlibs


In this case, following Alexandre's cross compilation work, it seems 
like the current solution of having headers adjusted for Wine works well 
and may be even better than trying to sync it. Still, a bit of 
coordination would be nice. What I'm esp. afraid of is how msvcrt 
importlib works. On mingw-w64, it needs some additions to support 
building with different CRTs, most notably UCRT. Those additions were 
already causing problems to Wine. It's fixed now, but it would be nice 
to make sure that we don't break again if we ever need more such 
additions (which is likely as UCRT support matures).



Current Wine solution of using a mix of its own importlib and default 
libmsvcrt.a should work fine in most cases. The case when it won't is 
when default mingw-w64 crt is not msvcrt-os. This is broader problem 
than just for Wine, it just happens to be more critical for Wine. With 
clang there is a solution of explicitly linking CRT DLL. We could 
probably try to upstream something similar to GCC.



Jacek



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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 22/05/2019 21:45, Jacek Caban wrote:


- mingw-w64 name

There have been talks about rebranding mingw-w64 for a long time 
(longer than I am in joined the project). While it's a good name for a 
branch, an established project that is no longer related to mingw.org 
could have a better branding. Kai mentioned that ironcrate was 
considered as some point, but to my knowledge no action was taken at 
that time. Alexandre offered lately that Wine brand could be used for 
mingw-w64 as well. I personally like the idea. Wine is already well 
recognised brand and brings roughly right associations. So... how 
about WineSDK?



Based on feedback I received (both in this thread and in private 
channels), it's clear that it's not what community wants. I think there 
was a lot of confusion, mostly based on false assumption that name 
change implies other changes. Anyway, keeping mingw-64 name is the 
easiest thing to do and that's fine with me.



If anyone wants to follow up on the name, feel free. I think one idea I 
received that seems worth mentioning in public is maxgw.



I will follow up in other replies on other threads.


Thanks,

Jacek



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

Re: [Mingw-w64-public] Patches for various headers

[Jacek Caban]

On 5/23/19 5:28 AM, Tom Ritter wrote:

On Wed, 22 May 2019 at 16:53, Jacek Caban  wrote:

[Fixes]

Thanks!  Here are updated versions.



Those look good, pushed to git.


Thanks,

Jacek



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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 5/23/19 9:22 AM, Biswapriyo Nath wrote:

Thank you for this great idea. I agree with the cooperation. But I have
some questions and concerns.

1. What will happen to all the mails, patches, users contributions, issues,
releases etc.?



If we move ML, it would go to new ML. Same for issues. Transaction would 
have to be smooth, meaning probably keeping both active for a while.




2. Where should we now send the emails and patches? I would suggest for a
separate mailing list.



Do you mean splitting mingw-w64-public into two separated lists: one for 
patches and one for general discussion? That could probably be done, but 
I'm not sure we have enough traffic to justify that.




3. Will all the coding practices, restrictions (e.g. c89) of wine
repository also apply to mingw-w64 repo?



For shared parts, I guess we'd need some adjustments from both sides. I 
wouldn't expect it to be too bad, note that it's already true for parts 
that are already shared.



As a side note, Wine uses mostly C89, but it's not exactly strict about 
that (nor enforces that by compiler flags). What's important is 
compatibility with relevant environments, standard is just a tool for 
that, not a goal on its own. mingw-w64, on the other hand, supports and 
has to continue supporting applications using -std=c89, so it has 
stricter C89 compliance requirement already.




4. What will happen to the other dependent FOSS projects like ReactOS,
msys2, cygwin etc.? Are they aware of this thought?



Why would anything change for them? Suggestions mostly involve workflow, 
not the end product structure. My email was meant to inform interested 
parties and exchange thoughts and ideas. I think their developers are on 
this ML, but if you think we should send it to their MLs, please forward it.




5. Many Linux distributions have their own packages and patches, what about
them?



Such patches need to be rebased on each release regardless how it's 
done, so nothing changes. (And, as usually, ideally they would be 
upstreamed, but it's not relevant to this discussion).




Last one, in my opinion, I will not vote for the rebranding/renaming the
repository because that may cause many confusion to normal users who are
used to saying the name. There are hundreds of forums (also the whole Stack
Exchange) where "mingw-w64" is a thing :)



Noted, thanks.


Jacek



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

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 5/23/19 11:52 AM, NightStrike wrote:

On Wed, May 22, 2019 at 3:44 PM Jacek Caban  wrote:

Hi all,

[I'm addressing it to both mingw-w64-public and wine-devel]

As most of you know, Wine and mingw-w64 have a lot in common and
cooperate to some extend for quite a while. There have been talks about
tightening this relationship for years. Recent Wine move to using PE
files for its builds led us to revisit those ideas. My feeling so far is
that there is an agreement among people I heard from that it's a good
direction for both projects to have mingw-w64 under an umbrella of the
Wine project.

I've never heard this before, but I would tend to disagree that this
is a good direction.  For some history here, I will highlight that I
am a huge proponent of collaboration.  If you recall, Jacek, it was me
that wandered into your IRC channel over ten years ago now begging for
your help on this project, and it's been a very long (and productive!)
road since then.



I wouldn't want to accidentally put words into someone else's mouth, I'd 
rather have interested parties speak for themselves, but for sake of 
transparency let me give you a quick summary. The idea of having 
mingw-w64 under Wine umbrella came from Kai in our private conversation 
a few years ago. Nothing happened until a few weeks ago when I mentioned 
that to Alexandre, who also thought it's worth talking about, and we 
reached Kai. We exchanged a few e-mails and contacted a few other 
contributors to get a sense of opinions. My apologies for not including 
you in that conversation, I haven't seen you around for years. 
Ultimately no decision was made and I think this should be discussed in 
public before doing any step. That's the purpose of my e-mail. I 
wouldn't call it takeover but rather discussing ideas.




Admittedly, my participation has dropped off
considerably given my current occupation, but I pushed hard for the
same collaboration with many other projects: Firefox, ReactOS, Fedora,
Ubuntu, Cygwin, every open source game I could find, even Chromium
(that one didn't work out).  In all cases, we pushed for
collaboration, not takeovers.  A prime example of this is msys2, which
was incubated as a subproject under mingw-w64, but rapidly grew into
its own.



What takeover are you talking about? Merge maybe, if desired. 
Collaboration, definitely. And I really don't see how proposed changes 
would have negative effect on other projects. Why would msys2 (or other 
projects) be in any different situation than it is now?




It would be great to move forward with this. Let me discuss a few
aspects of the idea.

- Infrastructure

mingw-w64 currently mostly depends heavily on SourceForge. While I'm
thankful to SF for years of free support, it's doesn't feel like an
optimal choice those days.

Why not?  SF provides a tremendous amount of service for free, with
impeccable uptime.  There was a point in time where we were uploading
several terabytes a day to the file storage area, for instance.  They
supported this with no issue.  They provide near immediate service via
IRC, and offer a lot of additional capability that we could take
advantage of if we needed to.



That's not the experience I had, but for the most notable thing see 
controversies paragraph:


https://en.wikipedia.org/wiki/SourceForge



Wine has its own infrastructure that
mingw-w64 could use right away. Moving things like mailing list, bug
tracker, etc. is straightforward to do, except for one thing... how
should it be called? Which brings us to the next item.

What functionality does Wine provide that exceeds what we currently
have that we couldn't take advantage of today?



Flexibility? Customization?



- mingw-w64 name

There have been talks about rebranding mingw-w64 for a long time (longer
than I am in joined the project). While it's a good name for a branch,
an established project that is no longer related to mingw.org could have
a better branding. Kai mentioned that ironcrate was considered as some
point, but to my knowledge no action was taken at that time. Alexandre
offered lately that Wine brand could be used for mingw-w64 as well. I
personally like the idea. Wine is already well recognised brand and
brings roughly right associations. So... how about WineSDK?

Absolutely not.  First, ironcrate was a codename for development
efforts of subprojects within mingw-w64, the largest of which was
winpthreads.  But second, mingw-w64 is a well established brand that
is today significantly more recognizable than the predecessor
mingw.org.  There is a very high cost of changing names, which is why
we haven't done it yet.  I don't see any upside of doing so.



Noted. I won't pursue it if that's a common sense. Is it?



- Source code sharing

Technically, we could share much more code than we currently do.
Duplicating efforts is quite suboptimal for everyone. Right now
mingw-w64 imports a number of platform headers and widl tool from Wine
via wine-import.sh script. Wine has a few

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

Hi Ruben,


On 22/05/2019 22:17, Ruben Van Boxem wrote:

All this probably is a great idea :). I just have (entirely worthless) 2c
two share on one point you bring up:



Thanks for sharing the opinion, it's definitely not worthless ;)



Op wo 22 mei 2019 om 21:44 schreef Jacek Caban :


- mingw-w64 name

There have been talks about rebranding mingw-w64 for a long time (longer
than I am in joined the project). While it's a good name for a branch,
an established project that is no longer related to mingw.org could have
a better branding. Kai mentioned that ironcrate was considered as some
point, but to my knowledge no action was taken at that time. Alexandre
offered lately that Wine brand could be used for mingw-w64 as well. I
personally like the idea. Wine is already well recognised brand and
brings roughly right associations. So... how about WineSDK?


The thing is, "mingw" is also a "recognized name".



Agreed, mingw (as in just mingw, replacing the original project) would 
be my first choice actually. The problem is that we can't use that 
without mingw.org authors' approval and I don't expect it coming (even 
using mingw-w64 could be considered controversial without approval).



Name similarity does not help users either, see recent case in mingw.org 
ML for an example:


https://osdn.net/projects/mingw/lists/archive/users/2019-May/000295.html



Not only as what it
stands for (minimalistic gnu for windows, although I never understood that
name to describe a windows API implementation...), but also as a toolchain
*target*.

Technically, a lot of things are named to match "mingw" (GCC and Clang
target names, for example). It has even grown out to its own frankenstein
ABI of sorts, next to the MSVC ABI on Windows.



Yes, compiler triplets need to stay as they are, at least for 
foreseeable future.




The suggestion to name it WineSDK (very close to WinSDK, clever that ;-) )
seems like a missed oportunity: it would seem to tie the purpose of
"mingw-w64" to Wine, which (for me, and a lot of other people) not the
primary goal of this project.
That goal is providing an "implementation" of the Windows API such that one
can generate code that runs on Windows without proprietary tools. The fact
that there is a lot of code shared with Wine or where it's hosted doesn't
change that, IMHO.



That's a fair concern. Explaining such confusion seems easier than 
promoting a fresh new name. Of course keeping the existing name is even 
easier if that's the consensus.



Also, Wine is called a compatibility layer. You may think of mingw-w64 
as a compatibility layer as well: it provides Windows compatibility to 
compiler toolchain ;)



Thanks,

Jacek



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

[Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

Hi all,

[I'm addressing it to both mingw-w64-public and wine-devel]

As most of you know, Wine and mingw-w64 have a lot in common and 
cooperate to some extend for quite a while. There have been talks about 
tightening this relationship for years. Recent Wine move to using PE 
files for its builds led us to revisit those ideas. My feeling so far is 
that there is an agreement among people I heard from that it's a good 
direction for both projects to have mingw-w64 under an umbrella of the 
Wine project.



It would be great to move forward with this. Let me discuss a few 
aspects of the idea.



- Infrastructure

mingw-w64 currently mostly depends heavily on SourceForge. While I'm 
thankful to SF for years of free support, it's doesn't feel like an 
optimal choice those days. Wine has its own infrastructure that 
mingw-w64 could use right away. Moving things like mailing list, bug 
tracker, etc. is straightforward to do, except for one thing... how 
should it be called? Which brings us to the next item.



- mingw-w64 name

There have been talks about rebranding mingw-w64 for a long time (longer 
than I am in joined the project). While it's a good name for a branch, 
an established project that is no longer related to mingw.org could have 
a better branding. Kai mentioned that ironcrate was considered as some 
point, but to my knowledge no action was taken at that time. Alexandre 
offered lately that Wine brand could be used for mingw-w64 as well. I 
personally like the idea. Wine is already well recognised brand and 
brings roughly right associations. So... how about WineSDK?



- Source code sharing

Technically, we could share much more code than we currently do. 
Duplicating efforts is quite suboptimal for everyone. Right now 
mingw-w64 imports a number of platform headers and widl tool from Wine 
via wine-import.sh script. Wine has a few headers imported from 
mingw-w64 as well. It works to some extend, but the fact is that we 
still duplicate more than we share. I'm not yet sure how to fix that 
entirely, but I'd like us to have a workflow that would limit the 
duplication.



- Testing

Wine has a TestBot and a number of test cases, which is a great tool for 
developers to make sure their patches are right. mingw-w64 does not have 
such thing and mostly depends on developers doing their own testing and 
regression reports after the patch is committed. We could integrate 
mingw-w64 testing with Wine TestBot to make sure that we don't break 
things (well, at least limit that possibility). I believe that it would 
nicely accelerate mingw-w64 development workflow as well as ensure that 
mingw-w64+Wine don't regress.



- WineConf

The annual Wine conference is a nice chance to meet other contributors 
in person:

https://wiki.winehq.org/WineConf
It would be great mingw-w64 developers there as well.


Any ideas, comments and thoughts on this topics are welcomed.


Thanks,
Jacek



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

Re: [Mingw-w64-public] Patches for various headers

[Jacek Caban]

Hi Tom,

I committed specstrings.h patch.

On 5/22/19 6:12 PM, Tom Ritter wrote:


+#define_Benign_race_begin_  __pragma(warning(push))
+#define_Benign_race_end_  __pragma(warning(pop))
+#define_No_competing_thread_begin_  __pragma(warning(push))
+#define_No_competing_thread_end_  __pragma(warning(pop))



I'm not sure how portable __pragma is, but since you don't modify 
warnings anyway, I think it would be safer to make those macros no-op as 
well.





diff --git a/mingw-w64-headers/include/processthreadsapi.h 
b/mingw-w64-headers/include/processthreadsapi.h
index 931a6f13..b34c87c6 100644
--- a/mingw-w64-headers/include/processthreadsapi.h
+++ b/mingw-w64-headers/include/processthreadsapi.h
@@ -165,6 +165,16 @@ WINBASEAPI WINBOOL WINAPI TerminateProcess (HANDLE 
hProcess, UINT uExitCode);
{
  return (HANDLE)(LONG_PTR) (-6);
}
+
+  typedef struct _MEMORY_PRIORITY_INFORMATION {
+ULONG MemoryPriority;
+  } MEMORY_PRIORITY_INFORMATION, *PMEMORY_PRIORITY_INFORMATION;
+
+  #define MEMORY_PRIORITY_VERY_LOW  1
+  #define MEMORY_PRIORITY_LOW   2
+  #define MEMORY_PRIORITY_MEDIUM3
+  #define MEMORY_PRIORITY_BELOW_NORMAL  4
+  #define MEMORY_PRIORITY_NORMAL5
  #endif



It looks good, but we already have those in winbase.h (where I older 
SDKs had it probably). Please remove them from winbase.h.



Thanks,

Jacek


___
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] crt: Call the right function for newmode from ucrtbase's __getmainargs

[Jacek Caban]

Hi Martin,

The patch looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.

[Jacek Caban]

On 5/17/19 10:11 PM, Martin Storsjö wrote:

On Fri, 17 May 2019, Jacek Caban wrote:


I see it now. The problem seems to be wider than assert and caused by
__set_app_type call in ucrtbase_main.c. If I remove them, it behaves
correctly. Do you remember it's called there? Note that crtexe.c already
sets app type correctly, but it's broken by __getmainargs later.


I think the reason why I added the __set_app_type call in 
__getmainargs, is that I checked with the wine implementation of the 
function for hints about what it should do, when implementing this for 
the ucrt compat wrapping.


Wine's function looks like this:

int CDECL __getmainargs(int *argc, char** *argv, char** *envp,
 int expand_wildcards, int *new_mode)
{
...
    if (new_mode)
    MSVCRT__set_new_mode( *new_mode );
    return 0;
}


But now when looking at the mingw-w64 crt code, I see that *new_mode 
always is 0 here - so apparently msvcrt.dll doesn't actually use the 
parameter in this exact way. 



new_mode seems to be something different than app type and we could 
probably use _set_new_mode for that, but we should be fine ignoring it.


Jacek



___
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] crt: Don't call __set_app_type from ucrtbase's __getmainargs

[Jacek Caban]

Signed-off-by: Jacek Caban 


___
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/2] crt: Use importlib for _assert.

[Jacek Caban]

On 5/17/19 10:02 PM, Jacek Caban wrote:
The problem seems to be wider than assert and caused by __set_app_type 
call in ucrtbase_main.c.



I obviously meant ucrtbase_compat.c.


Jacek



___
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/2] crt: Use importlib for _assert.

[Jacek Caban]

On 5/17/19 9:21 PM, Martin Storsjö wrote:

On Fri, 17 May 2019, Jacek Caban wrote:


On 5/17/19 10:44 AM, Martin Storsjö wrote:

On Fri, 29 Mar 2019, Jacek Caban wrote:


On 3/29/19 8:26 PM, Martin Storsjö wrote:

On Fri, 29 Mar 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am |  2 +-
.../api-ms-win-crt-runtime-l1-1-0.def.in  |  2 +-
mingw-w64-crt/lib-common/msvcrt.def.in    |  2 +-
mingw-w64-crt/lib-common/ucrtbase.def.in  |  2 +-
mingw-w64-crt/lib32/msvcr100.def.in   |  2 +-
mingw-w64-crt/lib32/msvcr80.def.in    |  2 +-
mingw-w64-crt/lib32/msvcr90.def.in    |  2 +-
mingw-w64-crt/lib32/msvcr90d.def.in   |  2 +-
mingw-w64-crt/lib64/msvcr100.def.in   |  2 +-
mingw-w64-crt/lib64/msvcr80.def.in    |  2 +-
mingw-w64-crt/lib64/msvcr90.def.in    |  2 +-
mingw-w64-crt/lib64/msvcr90d.def.in   |  2 +-
mingw-w64-crt/misc/assert.c   | 31 
---

mingw-w64-headers/crt/assert.h    |  3 +-
14 files changed, 13 insertions(+), 45 deletions(-)
delete mode 100644 mingw-w64-crt/misc/assert.c


LGTM (Do you happen to know why this was this way to begin with? 
It seems to me that this function existed even already in win2k.) 



I don't know, maybe win9x? It has been in the tree since "Add 
initial snapshot of runtime crt." commit and I didn't dig in 
mingw.org history.


It turned out that this had some other consequences.

If debugging an app with gdb, one could previously catch those 
asserts in gdb and do meaningful debugging around them (according to 
the reporter).


Now, asserts trigger the msvcrt's assertion failure dialog, which 
doesn't really seem to interact quite as well with gdb.



Previously, a console exe would exit cleanly within gdb on assertion 
failures, but putting a breakpoint on "abort" seems to stop at a 
good point. A GUI exe opens a dialog box, but I can't seem to be 
able to catch the abort in gdb in that case. (Does anyone have 
better insight into how to catch it better?)


Now when using the msvcrt's assert, even console exes pop up the 
dialog, and catching the abort from there doesn't seem to work. 



That's not what I see. I remember testing that previously and just 
confirmed that -mconsole/-mwindows switch works and assert uses 
console or window depending on it.


Right, this seems to be a msvcrt vs ucrt difference; with ucrt, it 
always uses a window.



I see it now. The problem seems to be wider than assert and caused by 
__set_app_type call in ucrtbase_main.c. If I remove them, it behaves 
correctly. Do you remember it's called there? Note that crtexe.c already 
sets app type correctly, but it's broken by __getmainargs later.



Jacek


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

Re: [Mingw-w64-public] Update OpenGL headers

[Jacek Caban]

On 5/17/19 12:42 PM, LRN wrote:

On 10.05.2019 16:28, LRN wrote:

On 10.05.2019 15:53, NightStrike wrote:

On Fri, May 10, 2019, 5:24 AM LRN wrote:


TBH, i'm starting to think that we should radically cut the GL headers
down and
only ship GL.h and GLU.h, just like MS does (and also glaux.h, probably).
The
rest can be installed separately.

In case anyone still thinks that shipping a full set of OpenGL headers in
MinGW-w64-headers is a good idea, here's the patch that updates the
headers to
a fresh git revision.

Why remove them?

Because someone has to keep them up to date as long as they are part of
mingw-w64-headers.

An analogy: if we pretend for a second that a small part of the Boost headers
(that Boost authors do not edit) is documented to be mandatory for inclusion in
mingw-w64-headers, then shipping all GL headers is equivalent to shipping all
Boost headers.


So, it's been a week. Any other opinions? Does anyone want the patch to be 
pushed?



FWIW, I agree that we shouldn't have those headers in the tree. I don't 
know if anyone already depends on that already, so I'm not sure what to 
do...



As long as we have them in the tree, the update is fine with me.


Thanks,

Jacek



___
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/2] crt: Use importlib for _assert.

[Jacek Caban]

On 5/17/19 10:44 AM, Martin Storsjö wrote:

On Fri, 29 Mar 2019, Jacek Caban wrote:


On 3/29/19 8:26 PM, Martin Storsjö wrote:

On Fri, 29 Mar 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am |  2 +-
.../api-ms-win-crt-runtime-l1-1-0.def.in  |  2 +-
mingw-w64-crt/lib-common/msvcrt.def.in    |  2 +-
mingw-w64-crt/lib-common/ucrtbase.def.in  |  2 +-
mingw-w64-crt/lib32/msvcr100.def.in   |  2 +-
mingw-w64-crt/lib32/msvcr80.def.in    |  2 +-
mingw-w64-crt/lib32/msvcr90.def.in    |  2 +-
mingw-w64-crt/lib32/msvcr90d.def.in   |  2 +-
mingw-w64-crt/lib64/msvcr100.def.in   |  2 +-
mingw-w64-crt/lib64/msvcr80.def.in    |  2 +-
mingw-w64-crt/lib64/msvcr90.def.in    |  2 +-
mingw-w64-crt/lib64/msvcr90d.def.in   |  2 +-
mingw-w64-crt/misc/assert.c   | 31 ---
mingw-w64-headers/crt/assert.h    |  3 +-
14 files changed, 13 insertions(+), 45 deletions(-)
delete mode 100644 mingw-w64-crt/misc/assert.c


LGTM (Do you happen to know why this was this way to begin with? It 
seems to me that this function existed even already in win2k.) 



I don't know, maybe win9x? It has been in the tree since "Add initial 
snapshot of runtime crt." commit and I didn't dig in mingw.org history.


It turned out that this had some other consequences.

If debugging an app with gdb, one could previously catch those asserts 
in gdb and do meaningful debugging around them (according to the 
reporter).


Now, asserts trigger the msvcrt's assertion failure dialog, which 
doesn't really seem to interact quite as well with gdb.



Previously, a console exe would exit cleanly within gdb on assertion 
failures, but putting a breakpoint on "abort" seems to stop at a good 
point. A GUI exe opens a dialog box, but I can't seem to be able to 
catch the abort in gdb in that case. (Does anyone have better insight 
into how to catch it better?)


Now when using the msvcrt's assert, even console exes pop up the 
dialog, and catching the abort from there doesn't seem to work. 



That's not what I see. I remember testing that previously and just 
confirmed that -mconsole/-mwindows switch works and assert uses console 
or window depending on it. If I get the dialog and click 'retry' button, 
it issues a break point that is properly handled by DBG. If I choose 
'break', the application quits using abort() and if I set breakpoint 
there, it's triggered. Same for console case, a breakpoint in abort() is 
hit.



I also tried to set SIGABRT handler that emits breakpoint in the test 
application itself. In such setting breakpoint in gdb is not needed.



Thanks,

Jacek



___
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/2] include/ddk: Synchronize with ReactOS (1/2).

[Jacek Caban]

On 5/14/19 7:46 AM, Liu Hao wrote:

在 2019/5/10 21:31, Jacek Caban 写道:

On 5/8/19 4:08 AM, Liu Hao wrote:

All DDK headers have been copied from
<https://github.com/reactos/reactos/tree/master/sdk/include/ddk>.
There are quite a few new headers which will be added later.

This commit contains all headers that have been modified.


What did you do about mingw-w64 modifications?


Jacek



There was no modification. Everything has been copied as is. I have no
idea whether it will work or not.



You can't just invalidate all commits that were made to mingw-w64 repo. 
They were made for reasons. It needs at least a careful review and 
probably upstreaming (or at least reapplying them on top of pulled 
changes) before we can do that.



Jacek



___
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/2] include/ddk: Synchronize with ReactOS (1/2).

[Jacek Caban]

On 5/8/19 4:08 AM, Liu Hao wrote:

All DDK headers have been copied from
.
There are quite a few new headers which will be added later.

This commit contains all headers that have been modified.



What did you do about mingw-w64 modifications?


Jacek



___
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] crt: Merge msvcr120_app.def.in for 32 and 64 bit x86

[Jacek Caban]

On 5/6/19 2:24 PM, Martin Storsjö wrote:

Also add differences for the arm32 version of the dll into the merged file.

Signed-off-by: Martin Storsjö 
---
  mingw-w64-crt/Makefile.am|8 +-
  mingw-w64-crt/lib-common/msvcr120_app.def.in | 2536 ++
  mingw-w64-crt/lib32/msvcr120_app.def.in  | 1664 
  mingw-w64-crt/lib64/msvcr120_app.def.in  | 1626 ---
  4 files changed, 2543 insertions(+), 3291 deletions(-)
  create mode 100644 mingw-w64-crt/lib-common/msvcr120_app.def.in
  delete mode 100644 mingw-w64-crt/lib32/msvcr120_app.def.in
  delete mode 100644 mingw-w64-crt/lib64/msvcr120_app.def.in



Looks good as well.


Thanks,

Jacek



___
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/2] crt: Provide an empty implementation of __set_app_type for msvcr120_app.dll

[Jacek Caban]

On 5/6/19 2:24 PM, Martin Storsjö wrote:

This dll doesn't provide this function, but making it an empty no-op
function should be fine.

This somewhat allows running exes linked against this dll; the previous
incorrect declaration of this function in the def files allowed
compiling projects (where configure checks otherwise would fail since
the mingw crt startup files has undefined references against this
function) that in the end produced dlls linking against it.

This CRT dll (which is intended only for use with Windows Store apps)
doesn't actually operate properly when used for standalone exe's though
(it crashes on exit and e.g. printf function calls doesn't output
anything), but this still is a small step towards making things less
incorrect.

Signed-off-by: Martin Storsjö



Looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH] headers: Use the msvcrt/ucrt setjmp functions on ARM64 is SEH is available

[Jacek Caban]

On 5/7/19 9:41 AM, Martin Storsjö wrote:

This requires using a new builtin intrinsic __builtin_sponentry(),
which was added in Clang 9.

Signed-off-by: Martin Storsjö 
---
The new intrinsic was added yesterday. After some time we could remove
the fallback setjmp/longjmp for ARM64, assuming that all users of
this arch have a new enough Clang with SEH enabled by default.
---



The patch looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH 6/6] headers: Change __MSVCRT_VERSION__ to use proper hexadecimal values for CRTs >= 10

[Jacek Caban]

On 5/6/19 1:10 PM, Martin Storsjö wrote:

On Mon, 6 May 2019, Jacek Caban wrote:


Hi Martin,


All patches look good to me.


Thanks! So you agree that it should practically be safe to change the 
value of this define and very few external users should be hit by the 
change? (In practice I have only recently added such checks in one 
place myself, which kind of initiated this whole patchset.) 



To be honest, I don't have a strong opinion about version values 
themselves. I think that the macro so far is an internal mingw-w64 
implementation detail. It's hidden behind configure option and so far 
that's the only reliable way for users to use it. Still, there are some 
other ways of modifying a spec files or clang -l trick, and for those 
users may needed __MSVCRT_VERSION__ before. You made it backward 
compatible with those versions in UCRT case. For msvcr1* versions it 
could break, but usage of the macro isn't needed for them in the first 
place, so it should be fine.



For the future, I'd prefer to consider -D_UCRT supported rather than 
-D__MSVCRT_VERSION__=0x...



Jacek



___
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/6] headers: Use _get_environ on all CRT versions except UCRT on ARM

[Jacek Caban]

On 5/6/19 1:08 PM, Martin Storsjö wrote:

On Mon, 6 May 2019, Jacek Caban wrote:


On 5/6/19 11:18 AM, Martin Storsjö wrote:

UCRT is handled in a separate ifdef further above.



The patch looks good, but I'm curious about possible future changes. 
It seems tempting to use UCRT variant for all crts (except 
problematic ARMs that have dedicated branch anyway) to unify builds 
and simplify the code. From your experience with porting to UCRT, 
would it cause problems for users?


You mean to provide and use e.g. (* __p__environ()) for the older 
CRTs, instead of a plain dllimported data variable? I think that's a 
good strategy in general, for the cases where it's feasible (e.g. not 
the arm pre-ucrt crts), it should be at least as flexible as the old 
method, and reduce differences between crts.



Yes, that's what I meant.




FWIW, on the topic of reducing differences between CRTs and making 
object files built with one header potentially work when linked with 
another one; the really major blocker on that front is struct 
threadlocaleinfostruct, which has got a totally different layout for 
UCRT, and use of it and its layout gets inlined in a number of e.g. 
ctype.h style functions. 



Yeah, that's a tricky one. We could probably try harder by adding some 
sort of locale info getter inside importlib, but it would probably need 
to be a mingw extension, so it's not really nice.



Jacek


___
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] crt: Add an implementation of gets() for msvcrt.dll for arm/arm64

[Jacek Caban]

Looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH 6/6] headers: Change __MSVCRT_VERSION__ to use proper hexadecimal values for CRTs >= 10

[Jacek Caban]

Hi Martin,


All patches look good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH 2/6] headers: Use _get_environ on all CRT versions except UCRT on ARM

[Jacek Caban]

On 5/6/19 11:18 AM, Martin Storsjö wrote:

UCRT is handled in a separate ifdef further above.



The patch looks good, but I'm curious about possible future changes. It 
seems tempting to use UCRT variant for all crts (except problematic ARMs 
that have dedicated branch anyway) to unify builds and simplify the 
code. From your experience with porting to UCRT, would it cause problems 
for users?



Thanks,

Jacek



___
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/3] winstorecompat: Remove the getpid fallback

[Jacek Caban]

On 4/15/19 3:10 PM, Martin Storsjö wrote:

All CRT variants should provide getpid in some form now.



Both this series and arm series look good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH] crt: Remove no longer used _encode_pointer and _decode_pointer.

[Jacek Caban]

On 4/15/19 3:03 PM, Martin Storsjö wrote:

On Mon, 15 Apr 2019, Jacek Caban wrote:


On 3/29/19 4:34 PM, Jacek Caban wrote:


Those are not used since a0ee49ec60f8a2a54e9991ef37501f62cfb07bdd.

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/crt/mingw_helpers.c  | 23 ---
 mingw-w64-crt/include/internal.h   |  4 
 mingw-w64-crt/lib32/msvcr90.def.in |  4 ++--
 mingw-w64-crt/lib64/msvcr90.def.in |  4 ++--
 4 files changed, 4 insertions(+), 31 deletions(-) 



Ping, is there any reason to keep it?


Liu OK'd this patch back in March soon after it was posted.



I missed it somehow, thanks.


In any case, I don't mind either, although I'm not really aware of the 
original purpose of these functions. 



They were used by the old (pre-ucrt-inspired) atexit() implementation, 
through even then they seemed questionable.



Jacek



___
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] crt: Remove no longer used _encode_pointer and _decode_pointer.

[Jacek Caban]

On 3/29/19 4:34 PM, Jacek Caban wrote:


Those are not used since a0ee49ec60f8a2a54e9991ef37501f62cfb07bdd.

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/crt/mingw_helpers.c  | 23 ---
 mingw-w64-crt/include/internal.h   |  4 
 mingw-w64-crt/lib32/msvcr90.def.in |  4 ++--
 mingw-w64-crt/lib64/msvcr90.def.in |  4 ++--
 4 files changed, 4 insertions(+), 31 deletions(-) 



Ping, is there any reason to keep it?


Jacek



___
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] crt: Implement a fallback _getpid function for msvcrt.dll for arm/arm64

[Jacek Caban]

On 4/15/19 1:56 PM, Martin Storsjö wrote:

On Mon, 15 Apr 2019, Jacek Caban wrote:


Hi Martin,

On 15/04/2019 12:50, Martin Storsjö wrote:

Signed-off-by: Martin Storsjö 
---
  mingw-w64-crt/Makefile.am   |  6 --
  mingw-w64-crt/misc/_getpid.c    | 18 ++
  mingw-w64-headers/crt/process.h |  4 
  3 files changed, 22 insertions(+), 6 deletions(-)
  create mode 100644 mingw-w64-crt/misc/_getpid.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 64d627ea8..a60b48d51 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -247,7 +247,8 @@ src_msvcrtarm32=\
    misc/__p___argv.c \
    misc/__p__acmdln.c \
    misc/__p__fmode.c \
-  misc/__p__wcmdln.c
+  misc/__p__wcmdln.c \
+  misc/_getpid.c
    if !ENABLE_SOFTMATH
  src_msvcrtarm32+=\
@@ -289,7 +290,8 @@ src_msvcrtarm64=\
    misc/__p___argv.c \
    misc/__p__acmdln.c \
    misc/__p__fmode.c \
-  misc/__p__wcmdln.c
+  misc/__p__wcmdln.c \
+  misc/_getpid.c
    src_msvcr80_64=\
    $(src_msvcrt_common) \
diff --git a/mingw-w64-crt/misc/_getpid.c 
b/mingw-w64-crt/misc/_getpid.c

new file mode 100644
index 0..da13b8edd
--- /dev/null
+++ b/mingw-w64-crt/misc/_getpid.c
@@ -0,0 +1,18 @@
+/**
+ * This file has no copyright assigned and is placed in the Public 
Domain.

+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within 
this package.

+ */
+
+#include 
+#include 
+
+int __cdecl _getpid(void) {
+  return GetCurrentProcessId();
+}
+
+int __cdecl getpid(void) {
+  return _getpid();
+}



At least _getpid (but probably both) should also have imp* symbol.


The patch does contain an __imp_ symbol for _getpid. (In the patch 
it's right next to the long diff/index/---/+++ lines for the next file 
so it's probably easy to miss when reading the diff.)



Oh, right, sorry, I'm blind. The patch looks good.




The unprefixed getpid() function isn't marked as _CRTIMP in the 
headers, so given that I don't think the function should need any 
__imp_ symbol.



It should probably be changed in the header, but it's not exactly 
related to the patch so we may leave it for now.





Also, can we remove getpid from winstorecompat after your patch? I 
wonder if the implementation there is a misplaced arm fix or is there 
any other reason to have it.


I believe that it's for a similar case; e.g. msvcr120_app also lacks 
getpid. If we add this stub there (and in any other msvcr variant that 
lacks _getpid), we could probably get rid of it from winstorecompat yes.


The slightly messy thing is that all of those include 
msvcrt-common.def.in, which adds the getpid == _getpid alias. So we 
need to add more defines (like the current #ifdef UCRTBASE) to e.g. 
msvcr120_app and similar ifdefs to msvcrt-common.def.in, to avoid 
accidentally adding the alias there. (Currently I believe msvcr120_app 
gets such an alias even though it shouldn't.)



Maybe #ifndef NO_GETPID_ALIAS would be a bit cleaner.


Jacek



___
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] crt: Implement a fallback _getpid function for msvcrt.dll for arm/arm64

[Jacek Caban]

Hi Martin,

On 15/04/2019 12:50, Martin Storsjö wrote:

Signed-off-by: Martin Storsjö 
---
  mingw-w64-crt/Makefile.am   |  6 --
  mingw-w64-crt/misc/_getpid.c| 18 ++
  mingw-w64-headers/crt/process.h |  4 
  3 files changed, 22 insertions(+), 6 deletions(-)
  create mode 100644 mingw-w64-crt/misc/_getpid.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 64d627ea8..a60b48d51 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -247,7 +247,8 @@ src_msvcrtarm32=\
misc/__p___argv.c \
misc/__p__acmdln.c \
misc/__p__fmode.c \
-  misc/__p__wcmdln.c
+  misc/__p__wcmdln.c \
+  misc/_getpid.c
  
  if !ENABLE_SOFTMATH

  src_msvcrtarm32+=\
@@ -289,7 +290,8 @@ src_msvcrtarm64=\
misc/__p___argv.c \
misc/__p__acmdln.c \
misc/__p__fmode.c \
-  misc/__p__wcmdln.c
+  misc/__p__wcmdln.c \
+  misc/_getpid.c
  
  src_msvcr80_64=\

$(src_msvcrt_common) \
diff --git a/mingw-w64-crt/misc/_getpid.c b/mingw-w64-crt/misc/_getpid.c
new file mode 100644
index 0..da13b8edd
--- /dev/null
+++ b/mingw-w64-crt/misc/_getpid.c
@@ -0,0 +1,18 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#include 
+#include 
+
+int __cdecl _getpid(void) {
+  return GetCurrentProcessId();
+}
+
+int __cdecl getpid(void) {
+  return _getpid();
+}



At least _getpid (but probably both) should also have imp* symbol.


Also, can we remove getpid from winstorecompat after your patch? I 
wonder if the implementation there is a misplaced arm fix or is there 
any other reason to have it.



Thanks,

Jacek



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

[Mingw-w64-public] [PATCH 1/2] pthread_unistd.h: Don't define _POSIX_THREAD_SAFE_FUNCTIONS.

[Jacek Caban]

Leave it up to time.h.

Signed-off-by: Jacek Caban 
---
 .../winpthreads/include/pthread_unistd.h  | 20 ---
 1 file changed, 20 deletions(-)


diff --git a/mingw-w64-libraries/winpthreads/include/pthread_unistd.h b/mingw-w64-libraries/winpthreads/include/pthread_unistd.h
index fd58d0d8..64693534 100644
--- a/mingw-w64-libraries/winpthreads/include/pthread_unistd.h
+++ b/mingw-w64-libraries/winpthreads/include/pthread_unistd.h
@@ -129,26 +129,6 @@
 #undef _POSIX_BARRIERS
 #define _POSIX_BARRIERS 200112L
 
-/* _SC_THREAD_SAFE_FUNCTIONS
-  Affected functions are
-
-  readdir_r(),
-  getgrgid_r(),
-  getgrnam_r(),
-  getpwnam_r(),
-  getpwuid_r(),
-  flockfile(),
-  ftrylockfile(),
-  funlockfile(),
-  getc_unlocked(),
-  getchar_unlocked(),
-  putc_unlocked(),
-  putchar_unlocked(),
-  strerror_r(),
-*/
-#undef _POSIX_THREAD_SAFE_FUNCTIONS
-#define _POSIX_THREAD_SAFE_FUNCTIONS 200112L
-
 /* _SC_TIMEOUTS
   The functions
 

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

[Mingw-w64-public] [PATCH 2/2] time.h: Use __forceinline for *_r functions.

[Jacek Caban]

This partially reverts 6988d73a95fbbd97a0bdbb517008cf18f4eb5f02. Some 
projects have their own static inline implementations that conflict with 
ours.


Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/crt/time.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)


diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index be2398d4..cd5a61dd 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -282,16 +282,16 @@ struct timezone {
 #endif
 
 #ifdef _POSIX_THREAD_SAFE_FUNCTIONS
-static __inline struct tm *__CRTDECL localtime_r(const time_t *_Time, struct tm *_Tm) {
+__forceinline struct tm *__CRTDECL localtime_r(const time_t *_Time, struct tm *_Tm) {
   return localtime_s(_Tm, _Time) ? NULL : _Tm;
 }
-static __inline struct tm *__CRTDECL gmtime_r(const time_t *_Time, struct tm *_Tm) {
+__forceinline struct tm *__CRTDECL gmtime_r(const time_t *_Time, struct tm *_Tm) {
   return gmtime_s(_Tm, _Time) ? NULL : _Tm;
 }
-static __inline char *__CRTDECL ctime_r(const time_t *_Time, char *_Str) {
+__forceinline char *__CRTDECL ctime_r(const time_t *_Time, char *_Str) {
   return ctime_s(_Str, 0x7fff, _Time) ? NULL : _Str;
 }
-static __inline char *__CRTDECL asctime_r(const struct tm *_Tm, char * _Str) {
+__forceinline char *__CRTDECL asctime_r(const struct tm *_Tm, char * _Str) {
   return asctime_s(_Str, 0x7fff, _Tm) ? NULL : _Str;
 }
 #endif

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

[Mingw-w64-public] [PATCH] winstorecompat: Remove no longer needed _wassert.

[Jacek Caban]

We no longer have the problematic _wassert in mingwex.

Signed-off-by: Jacek Caban 
---
 .../winstorecompat/Makefile.am|  1 -
 .../winstorecompat/src/_wassert.c | 50 ---
 2 files changed, 51 deletions(-)
 delete mode 100644 mingw-w64-libraries/winstorecompat/src/_wassert.c


diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am
index c8d6bb32..a5cb7f87 100644
--- a/mingw-w64-libraries/winstorecompat/Makefile.am
+++ b/mingw-w64-libraries/winstorecompat/Makefile.am
@@ -5,7 +5,6 @@ AM_CFLAGS = -Wall -Wstrict-aliasing=2 -pedantic
 lib_LIBRARIES = libwinstorecompat.a
 
 libwinstorecompat_a_SOURCES = \
-  src/_wassert.c \
   src/beginthread.c \
   src/GetModuleHandle.c \
   src/CreateEventW.c \
diff --git a/mingw-w64-libraries/winstorecompat/src/_wassert.c b/mingw-w64-libraries/winstorecompat/src/_wassert.c
deleted file mode 100644
index cd9b3ddd..
--- a/mingw-w64-libraries/winstorecompat/src/_wassert.c
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
-Copyright (c) 2013-2016 mingw-w64 project
-
-Contributing authors: Rafaël Carré
-
-Permission is hereby granted, free of charge, to any person obtaining a
-copy of this software and associated documentation files (the "Software"),
-to deal in the Software without restriction, including without limitation
-the rights to use, copy, modify, merge, publish, distribute, sublicense,
-and/or sell copies of the Software, and to permit persons to whom the
-Software is furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-DEALINGS IN THE SOFTWARE.
-*/
-
-#define _wassert ___wassert
-#include 
-#include 
-#include 
-#undef _wassert
-
-extern int mingw_app_type;
-
-void __cdecl _wassert(const wchar_t *_Message,const wchar_t *_File,unsigned _Line)
-{
-  wchar_t *msgbuf = (wchar_t *) malloc (8192*sizeof(wchar_t));
-
-  if (!_File || _File[0] == 0)
-_File = L"";
-  if (!_Message || _Message[0] == 0)
-_Message = L"?";
-  _snwprintf (msgbuf, 8191, 
-  L"Assertion failed!\n\nFile: %ws, Line %u\n\nExpression: %ws",
-  _File,_Line, _Message);
-  if (mingw_app_type == 0)
-fwprintf (stderr, L"%ws\n", msgbuf);
-  else
-OutputDebugStringW(msgbuf);
-
-  abort ();
-}

___
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] RFC: headers: Redirect _environ to the _get_environ function in msvcrt.dll for arm/arm64

[Jacek Caban]

On 4/10/19 11:15 PM, Martin Storsjö wrote:

On Wed, 10 Apr 2019, Jacek Caban wrote:


On 4/10/19 3:10 PM, Martin Storsjö wrote:

The direct _environ pointer is not available in msvcrt.dll on
arm/arm64. This provides a fallback read-only version of _environ,
but code that tries to write it still fails to compile though.



This header is getting messy. How about using UCRT path of defining 
_environ to *__p__environ() for all versions in the header (and thus 
simplify it) and move the nuance to importlib? You could then just 
put _get_environ hack there then.


Oh, maybe, hmm.

One downside (or upside depending on how you view it) is that it gives 
provides a writable pointer to an environ, but writing to it (which 
would write to a variable in the _get_environ wrapper) doesn't 
actually update the real environment.


That would fix one compilation error I'm running into in one place 
(gettext provides a setenv() replacement), but that setenv() 
replacement would of course be broken if it tries to touch that 
pointer. As _get_environ seems to be the only related function 
available in this msvcrt.dll, there's probably not much else to do, 
though.


Not that it probably matters though; when building for arm(64), 
there's little reason not to use ucrt anyway. I'm just trying to start 
regularly testing my toolchain builds with msvcrt as well. 



Oh, I missed the compile error part. Sure, that's better, the patch 
looks good.



Thanks,

Jacek



___
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] crt: arm: Use import libs for math functions

[Jacek Caban]

On 4/10/19 11:18 PM, Martin Storsjö wrote:

On Wed, 10 Apr 2019, Jacek Caban wrote:


On 4/10/19 3:11 PM, Martin Storsjö wrote:

This avoids unnecessary precision loss e.g. in the log2 function,
which previously was wrapped as log(x) / constant, which didn't
return exact integers for powers of two.

Some math functions are kept for msvcrt, while they are superfluous
for ucrt where all those functions exist already (in C99 compliant
form).

For msvcrt, use ceil/floor from the import library instead of a
local reimplementation. For all details I've tested in
https://github.com/mstorsjo/llvm-mingw/blob/master/test/crt-test.c,
the msvcrt.dll version of these functions on arm/arm64 are compliant.



It looks reasonable, but shouldn't we mark them in headers as 
dllimport as well?


Ideally, yes, but I fear that leads to quite a bit of churn in the 
headers. There's a bunch of other math functions already, that are 
implemented in libmingwex.a for x86, that just forward to the CRT on arm.


Especially as the set of functions that forward to the CRT differs 
between msvcrt and ucrt, and between x86 and arm. 



Fair enough, the patch is fine with me.


Thanks,

Jacek



___
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] RFC: headers: Redirect _environ to the _get_environ function in msvcrt.dll for arm/arm64

[Jacek Caban]

On 4/10/19 3:10 PM, Martin Storsjö wrote:

The direct _environ pointer is not available in msvcrt.dll on
arm/arm64. This provides a fallback read-only version of _environ,
but code that tries to write it still fails to compile though.



This header is getting messy. How about using UCRT path of defining 
_environ to *__p__environ() for all versions in the header (and thus 
simplify it) and move the nuance to importlib? You could then just put 
_get_environ hack there then.



Thanks,

Jacek



___
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/3] RFC: headers: Don't declare getpid for msvcrt versions where it's missing

[Jacek Caban]

On 4/10/19 3:09 PM, Martin Storsjö wrote:

If the getpid function is missing, user code might try to reimplement
it, with minor mismatches to the signature.

Signed-off-by: Martin Storsjö 



That looks reasonable to me.


Jacek



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

[Mingw-w64-public] [PATCH] time.h: Use static inlines for time 32/64-bit forwarding functions.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/crt/corecrt.h |  8 ++
 mingw-w64-headers/crt/time.h| 48 -
 2 files changed, 32 insertions(+), 24 deletions(-)


diff --git a/mingw-w64-headers/crt/corecrt.h b/mingw-w64-headers/crt/corecrt.h
index d171a013..44d32d62 100644
--- a/mingw-w64-headers/crt/corecrt.h
+++ b/mingw-w64-headers/crt/corecrt.h
@@ -143,6 +143,14 @@ typedef __time64_t time_t;
 #define _CRT_SECURE_CPP_NOTHROW throw()
 #endif
 
+#ifndef __CRTDECL
+#if !defined(__cplusplus) && defined(__GNUC__)
+#define __CRTDECL __cdecl __attribute__ ((__unused__))
+#else
+#define __CRTDECL __cdecl
+#endif
+#endif
+
 #if defined(__cplusplus) && _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES
 
 #define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(__ret,__func,__dsttype,__dst) \
diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index 02abd7b6..be2398d4 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -216,27 +216,27 @@ extern "C" {
 #ifndef RC_INVOKED
 
 #ifdef _USE_32BIT_TIME_T
-__forceinline time_t __cdecl time(time_t *_Time) { return _time32(_Time); }
-__forceinline double __cdecl difftime(time_t _Time1,time_t _Time2)  { return _difftime32(_Time1,_Time2); }
-__forceinline struct tm *__cdecl localtime(const time_t *_Time) { return _localtime32(_Time); }
-__forceinline errno_t __cdecl localtime_s(struct tm *_Tm,const time_t *_Time) { return _localtime32_s(_Tm,_Time); }
-__forceinline struct tm *__cdecl gmtime(const time_t *_Time) { return _gmtime32(_Time); }
-__forceinline errno_t __cdecl gmtime_s(struct tm *_Tm, const time_t *_Time)   { return _gmtime32_s(_Tm, _Time); }
-__forceinline char *__cdecl ctime(const time_t *_Time) { return _ctime32(_Time); }
-__forceinline errno_t __cdecl ctime_s(char *_Buf,size_t _SizeInBytes,const time_t *_Time) { return _ctime32_s(_Buf,_SizeInBytes,_Time); }
-__forceinline time_t __cdecl mktime(struct tm *_Tm) { return _mktime32(_Tm); }
-__forceinline time_t __cdecl _mkgmtime(struct tm *_Tm) { return _mkgmtime32(_Tm); }
+static __inline time_t __CRTDECL time(time_t *_Time) { return _time32(_Time); }
+static __inline double __CRTDECL difftime(time_t _Time1,time_t _Time2)  { return _difftime32(_Time1,_Time2); }
+static __inline struct tm *__CRTDECL localtime(const time_t *_Time) { return _localtime32(_Time); }
+static __inline errno_t __CRTDECL localtime_s(struct tm *_Tm,const time_t *_Time) { return _localtime32_s(_Tm,_Time); }
+static __inline struct tm *__CRTDECL gmtime(const time_t *_Time) { return _gmtime32(_Time); }
+static __inline errno_t __CRTDECL gmtime_s(struct tm *_Tm, const time_t *_Time)   { return _gmtime32_s(_Tm, _Time); }
+static __inline char *__CRTDECL ctime(const time_t *_Time) { return _ctime32(_Time); }
+static __inline errno_t __CRTDECL ctime_s(char *_Buf,size_t _SizeInBytes,const time_t *_Time) { return _ctime32_s(_Buf,_SizeInBytes,_Time); }
+static __inline time_t __CRTDECL mktime(struct tm *_Tm) { return _mktime32(_Tm); }
+static __inline time_t __CRTDECL _mkgmtime(struct tm *_Tm) { return _mkgmtime32(_Tm); }
 #else
-__forceinline time_t __cdecl time(time_t *_Time) { return _time64(_Time); }
-__forceinline double __cdecl difftime(time_t _Time1,time_t _Time2) { return _difftime64(_Time1,_Time2); }
-__forceinline struct tm *__cdecl localtime(const time_t *_Time) { return _localtime64(_Time); }
-__forceinline errno_t __cdecl localtime_s(struct tm *_Tm,const time_t *_Time) { return _localtime64_s(_Tm,_Time); }
-__forceinline struct tm *__cdecl gmtime(const time_t *_Time) { return _gmtime64(_Time); }
-__forceinline errno_t __cdecl gmtime_s(struct tm *_Tm, const time_t *_Time) { return _gmtime64_s(_Tm, _Time); }
-__forceinline char *__cdecl ctime(const time_t *_Time) { return _ctime64(_Time); }
-__forceinline errno_t __cdecl ctime_s(char *_Buf,size_t _SizeInBytes,const time_t *_Time) { return _ctime64_s(_Buf,_SizeInBytes,_Time); }
-__forceinline time_t __cdecl mktime(struct tm *_Tm) { return _mktime64(_Tm); }
-__forceinline time_t __cdecl _mkgmtime(struct tm *_Tm) { return _mkgmtime64(_Tm); }
+static __inline time_t __CRTDECL time(time_t *_Time) { return _time64(_Time); }
+static __inline double __CRTDECL difftime(time_t _Time1,time_t _Time2) { return _difftime64(_Time1,_Time2); }
+static __inline struct tm *__CRTDECL localtime(const time_t *_Time) { return _localtime64(_Time); }
+static __inline errno_t __CRTDECL localtime_s(struct tm *_Tm,const time_t *_Time) { return _localtime64_s(_Tm,_Time); }
+static __inline struct tm *__CRTDECL gmtime(const time_t *_Time) { return _gmtime64(_Time); }
+static __inline errno_t __CRTDECL gmtime_s(struct tm *_Tm, const time_t *_Time) { return _gmtime64_s(_Tm, _Time); }
+static __inline char *__CRTDECL ctime(const time_t *_Time) { return _ctime64(_Time); }
+static __inline errno_t __CRTDECL ctime_s(char *_Buf,size_t _SizeInBytes,const time_t *_Time) { return _ctime64_s(_Buf,_SizeInBytes,_Time); }
+static __inline time

Re: [Mingw-w64-public] [PATCH] crt: Use importlibs for more time functions.

[Jacek Caban]

On 4/5/19 3:43 PM, Martin Storsjö wrote:
How about doing things in msvc ucrt compatible way? Like the patch I 
attached as an example (not yet tested)?


This looks good to me (but didn't test it yet).

This approach of modernizing small areas at a time seems good also, 
wrt finding out what regressions it might cause, compared to larger 
refactorings of everything at once.


In general I think we should review all use of 
__forceinline/__CRT_INLINE wrt to what symbols actually are available 
in UCRT.




Testing looks good, I will send the patch for review.


Jacek


___
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] crt: Use importlibs for more time functions.

[Jacek Caban]

On 4/8/19 4:33 AM, Liu Hao wrote:

在 2019/4/5 下午8:07, Jacek Caban 写道:

On 4/5/19 9:15 AM, Martin Storsjö wrote:

It would be great to have __forceinline fixed. I've seen a problems in
code using static __forceinline multiple times. I also recall that
attempts to change that had their problems, so it's more tricky than it
seems (if possible).


The `extern` specifier is required in the case of C (but is not in C++)
because plain `inline` is not the same thing with `extern inline` [1].

When compiled as C++, `extern` has no effect on an `inline` function. If
the entire function body is inlined then no external definition is
emitted; otherwise a weak definition is emitted, so taking the address
of an inline function in all translate units returns the same value, and
no multiple definition errors may occur. I haven't heard of such a thing
in C89 mode; it could be achieved by using the `weak` or `selectany`
attribute with C99 `extern inline` semantics, anyway.



Sure, but what does it have to do with __forceinline? __forceinline is 
for functions that are really meant to be inlined and thus I think it 
should not try to preserve single pointer value. With removed extern, we 
leave the choice for user, one could still use extern __forceinline.



And in this particular context of time functions, we really don't want 
to allow compiler/linker using the available symbol. It may be a 
different variant of the function than was used by the header.



Jacek



___
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] crt: Use importlibs for more time functions.

[Jacek Caban]

On 4/5/19 9:15 AM, Martin Storsjö wrote:

On Thu, 4 Apr 2019, Jacek Caban wrote:


On 4/4/19 3:07 PM, Martin Storsjö wrote:

On Thu, 4 Apr 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am  |  2 +-
mingw-w64-crt/lib-common/msvcrt.def.in |  4 +-
mingw-w64-crt/lib32/msvcr100.def.in    |  4 +-
mingw-w64-crt/lib32/msvcr80.def.in |  2 +
mingw-w64-crt/lib32/msvcr90.def.in |  4 +-
mingw-w64-crt/lib64/msvcr100.def.in    |  4 +-
mingw-w64-crt/lib64/msvcr80.def.in |  2 +
mingw-w64-crt/lib64/msvcr90.def.in |  4 +-
mingw-w64-crt/misc/difftime.c  | 21 --
mingw-w64-crt/misc/difftime32.c    |  9 -
mingw-w64-crt/misc/difftime64.c    |  9 -
mingw-w64-headers/crt/time.h   | 55 +++---
12 files changed, 37 insertions(+), 83 deletions(-)
delete mode 100644 mingw-w64-crt/misc/difftime.c
delete mode 100644 mingw-w64-crt/misc/difftime32.c
delete mode 100644 mingw-w64-crt/misc/difftime64.c


Ok with me, if you extend the commit message to mention all the 
changes. The changes IMO now include the following three change 
categories:


- Use importlibs for more time functions
- Unify inline attribute strategies for time functions in headers
- Use _CRTIMP on more time functions 



Multiple line in commit message usually is a good sign that the patch 
should be split ;) And I agree, I could do better job at that. I 
split the patch and pushed.


This turned out to break compilation in certain cases for me.

The culprit is that __forceinline is a bit deceptive (and so is 
__CRT_INLINE). For good reasons I was using __mingw_static_ovr here 
before, for the UCRT case.


These three macros expand to slightly different things depending on 
compiler and context, but for the C, modern clang/gcc case, they are 
as follows:


#define __CRT_INLINE extern inline __attribute__((__gnu_inline__))
#define __forceinline extern __inline__ 
__attribute__((__always_inline__,__gnu_inline__))
#define __mingw_static_ovr static __attribute__ ((__unused__)) 
__inline__ __cdecl


Both __CRT_INLINE and __forceinline declare the inline functions as 
extern, in combination with the gnu_inline attribute. The gnu_inline 
attribute, in combination with extern, means that when you take the 
address of the function, it shouldn't generate and reference the 
inline version of the function, but reference the extern copy of the 
function available in another translation unit.


This obviously is desireable for getting the same function pointer to 
a function in all translation units that refer to it, but doesn't work 
for functions that don't exist elsewhere in that form.


I'm not sure about how many of the existing cases of __forceinline and 
__CRT_INLINE that really intentionally want this behaviour, so I've 
proceeded cautiously and used __mingw_static_ovr in a few places for 
UCRT where I otherwise ran into issues.


But in any case, we either need to add import library aliases for 
these cases (which doesn't work for things that vary depending on 
_USE_32BIT_TIME_T), remove extern from __forceinline and __CRT_INLINE, 
or use a different inline attribute (e.g. __mingw_static_ovr) for 
these particular inlines. 



It would be great to have __forceinline fixed. I've seen a problems in 
code using static __forceinline multiple times. I also recall that 
attempts to change that had their problems, so it's more tricky than it 
seems (if possible).



How about doing things in msvc ucrt compatible way? Like the patch I 
attached as an example (not yet tested)?



Jacek

diff --git a/mingw-w64-headers/crt/corecrt.h b/mingw-w64-headers/crt/corecrt.h
index d171a013..44d32d62 100644
--- a/mingw-w64-headers/crt/corecrt.h
+++ b/mingw-w64-headers/crt/corecrt.h
@@ -143,6 +143,14 @@ typedef __time64_t time_t;
 #define _CRT_SECURE_CPP_NOTHROW throw()
 #endif
 
+#ifndef __CRTDECL
+#if !defined(__cplusplus) && defined(__GNUC__)
+#define __CRTDECL __cdecl __attribute__ ((__unused__))
+#else
+#define __CRTDECL __cdecl
+#endif
+#endif
+
 #if defined(__cplusplus) && _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES
 
 #define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(__ret,__func,__dsttype,__dst) \
diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index 02abd7b6..be2398d4 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -216,27 +216,27 @@ extern "C" {
 #ifndef RC_INVOKED
 
 #ifdef _USE_32BIT_TIME_T
-__forceinline time_t __cdecl time(time_t *_Time) { return _time32(_Time); }
-__forceinline double __cdecl difftime(time_t _Time1,time_t _Time2)  { return _difftime32(_Time1,_Time2); }
-__forceinline struct tm *__cdecl localtime(const time_t *_Time) { return _localtime32(_Time); }
-__forceinline errno_t __cdecl localtime_s(struct tm *_Tm,const time_t *_Time) { return _localtime32_s(_Tm,_Time); }
-__forceinline struct tm *__cdecl gmtime(const time_t *_Time) { return _gmtime32(_Time); }
-__forceinline errno

Re: [Mingw-w64-public] [PATCH 1/2] crt: Get rid of _ftime from mingwex.

[Jacek Caban]

On 4/5/19 9:19 AM, Martin Storsjö wrote:

On Thu, 4 Apr 2019, Jacek Caban wrote:



It's already handled by importlibs.

Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am    |  2 +-
mingw-w64-crt/stdio/_ftime.c | 19 ---
2 files changed, 1 insertion(+), 20 deletions(-)
delete mode 100644 mingw-w64-crt/stdio/_ftime.c


This doesn't look correct. The patch talks about removing the function 
_ftime, but the removed _ftime.c actually contains definitions of the 
function ftime, without a leading underscore. There doesn't seem to be 
any underscore-less import lib aliases for this function. 



ftime (not underscored) is already forwarded to _ftime32/_ftime64 in 
sys/timeb.h, which are handled by importlibs. Anyway, we may skip it for 
now.



Thanks,

Jacek



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

[Mingw-w64-public] [PATCH 2/2] crt: Move __mingw_setusermatherr and __mingw_raise_matherr into a separated object file.

[Jacek Caban]

_matherr may be overridden by an application and as such the default 
implementation should be in a separated object file.


Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am   |  1 +
 mingw-w64-crt/crt/merr.c| 26 --
 mingw-w64-crt/crt/usermatherr.c | 32 
 3 files changed, 33 insertions(+), 26 deletions(-)
 create mode 100644 mingw-w64-crt/crt/usermatherr.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 57188d5c..d8a37898 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -119,6 +119,7 @@ src_libmingw32=include/oscalls.h include/internal.h include/sect_attribs.h \
   crt/cinitexe.c  crt/crt0_w.c crt/merr.c  crt/pesect.c  crt/udllargc.c  crt/xthdloc.ccrt/CRT_fp10.c \
   crt/mingw_custom.c  crt/mingw_helpers.c  \
   crt/pseudo-reloc.c  crt/udll_argv.c  \
+  crt/usermatherr.c   \
   crt/xtxtmode.c  crt/crt_handler.c\
   crt/tlsthrd.c   crt/tlsmthread.c crt/tlsmcrt.c   crt/cxa_atexit.c
 
diff --git a/mingw-w64-crt/crt/merr.c b/mingw-w64-crt/crt/merr.c
index f3dff580..687aab4a 100644
--- a/mingw-w64-crt/crt/merr.c
+++ b/mingw-w64-crt/crt/merr.c
@@ -4,35 +4,9 @@
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
 
-#include 
 #include 
 #include 
 
-typedef int (__cdecl *fUserMathErr)(struct _exception *);
-static fUserMathErr stUserMathErr;
-
-void __mingw_raise_matherr (int typ, const char *name, double a1, double a2,
-			double rslt)
-{
-  struct _exception ex;
-  if (!stUserMathErr)
-return;
-  ex.type = typ;
-  ex.name = (char*)name;
-  ex.arg1 = a1;
-  ex.arg2 = a2;
-  ex.retval = rslt;
-  (*stUserMathErr)();
-}
-
-#undef __setusermatherr
-
-void __mingw_setusermatherr (int (__cdecl *f)(struct _exception *))
-{
-  stUserMathErr = f;
-  __setusermatherr (f);
-}
-
 int __CRTDECL
 _matherr (struct _exception *pexcept)
 {
diff --git a/mingw-w64-crt/crt/usermatherr.c b/mingw-w64-crt/crt/usermatherr.c
new file mode 100644
index ..fce059e1
--- /dev/null
+++ b/mingw-w64-crt/crt/usermatherr.c
@@ -0,0 +1,32 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#include 
+
+typedef int (__cdecl *fUserMathErr)(struct _exception *);
+static fUserMathErr stUserMathErr;
+
+void __mingw_raise_matherr (int typ, const char *name, double a1, double a2,
+			double rslt)
+{
+  struct _exception ex;
+  if (!stUserMathErr)
+return;
+  ex.type = typ;
+  ex.name = (char*)name;
+  ex.arg1 = a1;
+  ex.arg2 = a2;
+  ex.retval = rslt;
+  (*stUserMathErr)();
+}
+
+#undef __setusermatherr
+
+void __mingw_setusermatherr (int (__cdecl *f)(struct _exception *))
+{
+  stUserMathErr = f;
+  __setusermatherr (f);
+}

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

[Mingw-w64-public] [PATCH 1/2] crt: Get rid of _ftime from mingwex.

[Jacek Caban]

It's already handled by importlibs.

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am|  2 +-
 mingw-w64-crt/stdio/_ftime.c | 19 ---
 2 files changed, 1 insertion(+), 20 deletions(-)
 delete mode 100644 mingw-w64-crt/stdio/_ftime.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index a30c890e..57188d5c 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -339,7 +339,7 @@ src_libmingwex=\
   stdio/vfscanf2.S stdio/vfwscanf2.S stdio/vscanf2.S  stdio/vsscanf2.S  stdio/vswscanf2.S \
   stdio/vwscanf2.S stdio/strtok_r.c  stdio/scanf.S \
   stdio/_Exit.cstdio/_findfirst64i32.c   stdio/_findnext64i32.c   stdio/_fstat.c \
-  stdio/_fstat64i32.c  stdio/_ftime.cstdio/_getc_nolock.c stdio/_getwc_nolock.c stdio/_putc_nolock.c\
+  stdio/_fstat64i32.c  stdio/_getc_nolock.c  stdio/_getwc_nolock.cstdio/_putc_nolock.c\
   stdio/_putwc_nolock.cstdio/_stat.c stdio/_stat64i32.c   stdio/_wfindfirst64i32.c  stdio/_wfindnext64i32.c \
   stdio/_wstat.c   stdio/_wstat64i32.c   stdio/asprintf.c stdio/atoll.c stdio/fgetpos64.c   \
   stdio/fopen64.c  stdio/fseeko32.c  stdio/fseeko64.c stdio/fsetpos64.c stdio/ftello.c  \
diff --git a/mingw-w64-crt/stdio/_ftime.c b/mingw-w64-crt/stdio/_ftime.c
deleted file mode 100644
index 0600790f..
--- a/mingw-w64-crt/stdio/_ftime.c
+++ /dev/null
@@ -1,19 +0,0 @@
-#define __CRT__NO_INLINE
-#include 
-#include 
-
-/* FIXME: Relying on _USE_32BIT_TIME_T, which is a user-macro,
-during CRT compilation is plainly broken.  Need an appropriate
-implementation to provide users the ability of compiling the
-CRT only with 32-bit time_t behavior. */
-#if defined(_USE_32BIT_TIME_T)
-void __cdecl ftime (struct timeb *b)
-{
-  return _ftime ((struct __timeb32 *)b);
-}
-#else
-void __cdecl ftime (struct timeb *b)
-{
-  _ftime64((struct __timeb64 *)b);
-}
-#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] crt: Use importlibs for more time functions.

[Jacek Caban]

On 4/4/19 3:07 PM, Martin Storsjö wrote:

On Thu, 4 Apr 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am  |  2 +-
mingw-w64-crt/lib-common/msvcrt.def.in |  4 +-
mingw-w64-crt/lib32/msvcr100.def.in    |  4 +-
mingw-w64-crt/lib32/msvcr80.def.in |  2 +
mingw-w64-crt/lib32/msvcr90.def.in |  4 +-
mingw-w64-crt/lib64/msvcr100.def.in    |  4 +-
mingw-w64-crt/lib64/msvcr80.def.in |  2 +
mingw-w64-crt/lib64/msvcr90.def.in |  4 +-
mingw-w64-crt/misc/difftime.c  | 21 --
mingw-w64-crt/misc/difftime32.c    |  9 -
mingw-w64-crt/misc/difftime64.c    |  9 -
mingw-w64-headers/crt/time.h   | 55 +++---
12 files changed, 37 insertions(+), 83 deletions(-)
delete mode 100644 mingw-w64-crt/misc/difftime.c
delete mode 100644 mingw-w64-crt/misc/difftime32.c
delete mode 100644 mingw-w64-crt/misc/difftime64.c


Ok with me, if you extend the commit message to mention all the 
changes. The changes IMO now include the following three change 
categories:


- Use importlibs for more time functions
- Unify inline attribute strategies for time functions in headers
- Use _CRTIMP on more time functions 



Multiple line in commit message usually is a good sign that the patch 
should be split ;) And I agree, I could do better job at that. I split 
the patch and pushed.



Thanks or the review,

Jacek



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

[Mingw-w64-public] [PATCH] crt: Use importlibs for more time functions.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am  |  2 +-
 mingw-w64-crt/lib-common/msvcrt.def.in |  4 +-
 mingw-w64-crt/lib32/msvcr100.def.in|  4 +-
 mingw-w64-crt/lib32/msvcr80.def.in |  2 +
 mingw-w64-crt/lib32/msvcr90.def.in |  4 +-
 mingw-w64-crt/lib64/msvcr100.def.in|  4 +-
 mingw-w64-crt/lib64/msvcr80.def.in |  2 +
 mingw-w64-crt/lib64/msvcr90.def.in |  4 +-
 mingw-w64-crt/misc/difftime.c  | 21 --
 mingw-w64-crt/misc/difftime32.c|  9 -
 mingw-w64-crt/misc/difftime64.c|  9 -
 mingw-w64-headers/crt/time.h   | 55 +++---
 12 files changed, 37 insertions(+), 83 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/difftime.c
 delete mode 100644 mingw-w64-crt/misc/difftime32.c
 delete mode 100644 mingw-w64-crt/misc/difftime64.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 689a17c7..a30c890e 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -317,7 +317,7 @@ src_libmingwex=\
   misc/mingw_getsp.S \
   misc/alarm.c \
   misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
-  misc/delayimp.cmisc/difftime.cmisc/difftime32.c   misc/difftime64.cmisc/dirent.c  \
+  misc/delayimp.cmisc/dirent.c  \
   misc/dirname.c \
   misc/feclearexcept.c   misc/fegetenv.cmisc/fegetexceptflag.c  misc/fegetround.cmisc/feholdexcept.c\
   misc/feraiseexcept.c   misc/fesetenv.cmisc/fesetexceptflag.c  misc/fesetround.cmisc/fetestexcept.c\
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index bc9c0c63..1c4f4089 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -456,8 +456,8 @@ _cwscanf_s
 _cwscanf_s_l
 _dstbias DATA
 F_ARM_ANY(_daylight DATA)
-F_ARM_ANY(_difftime32)
-F_ARM_ANY(_difftime64)
+_difftime32 F_I386(== difftime)
+_difftime64
 _dup
 _dup2
 _ecvt
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in b/mingw-w64-crt/lib32/msvcr100.def.in
index e58937d4..8bc4f514 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -805,8 +805,8 @@ _cwscanf
 _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in b/mingw-w64-crt/lib32/msvcr80.def.in
index 4914931d..c1092e83 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -141,6 +141,8 @@ _creat
 _cscanf
 _ctype DATA
 _cwait
+_difftime32
+_difftime64
 _dstbias DATA
 _dup
 _dup2
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in b/mingw-w64-crt/lib32/msvcr90.def.in
index 182ec506..ada4f638 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -431,8 +431,8 @@ _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
 _decode_pointer DATA
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in b/mingw-w64-crt/lib64/msvcr100.def.in
index c081fea2..5faa3619 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -763,8 +763,8 @@ _cwscanf
 _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in b/mingw-w64-crt/lib64/msvcr80.def.in
index 8b900603..6c6a5518 100644
--- a/mingw-w64-crt/lib64/msvcr80.def.in
+++ b/mingw-w64-crt/lib64/msvcr80.def.in
@@ -231,6 +231,8 @@ _ctype
 _cwait
 _cwprintf
 _cwscanf
+_difftime32
+_difftime64
 _dstbias DATA
 _dup
 _dup2
diff --git a/mingw-w64-crt/lib64/msvcr90.def.in b/mingw-w64-crt/lib64/msvcr90.def.in
index 2ff5050b..14923195 100644
--- a/mingw-w64-crt/lib64/msvcr90.def.in
+++ b/mingw-w64-crt/lib64/msvcr90.def.in
@@ -379,8 +379,8 @@ _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
 _decode_pointer DATA
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/misc/difftime.c b/mingw-w64-crt/misc/difftime.c
deleted file mode 100644
index 5d49f529..
--- a/mingw-w64-crt/misc/difftime.c
+++ /dev/null
@@ -1,21 +0,0 @@
-#define __CRT__NO_INLINE
-#include 
-#include 
-
-/* FIXME: Relying on _USE_32BIT_TIME_T, which is a user-macro,
-during CRT compilation is plainly broken.  Need an appropriate
-implementation to provide users the ability of compiling the
-CRT only with 32-bit time_t behavior. */
-
-#ifndef _USE_32BIT_TIME_T
-double __cdecl difftime(time_t _Time1,time_t _Time2)
-{
-  return _difftime64(_Time1,_Time2);
-}
-#else
-double __cdecl difftime(time_t _Time1,time_t _Time2)
-{
-  return _difftime32(_Time1,_Time2);
-}
-#endif
-
diff --git a/mingw-w64-crt/misc/difftime32.c b/mingw-w64-crt/misc/difftime32.c
deleted file mode 100644
index

Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlibs for difftime* functions.

[Jacek Caban]

On 4/3/19 9:13 PM, Martin Storsjö wrote:

On Wed, 3 Apr 2019, Jacek Caban wrote:

Don't you have 32/64 the wrong way around here?



Oh, good catch, those #ifdefs used opposite meaning and my test was 
stupid enough to not catch it.





I'm not quite sure about the nuance and difference in intent between 
the __TIME_INLINE and __forceinline blocks here, but I guess it's ok 
if it works in practice (except for the swapped functions). 



__TIME_INLINE is related with __CRT_INLINE which is mostly used in 
combination with __CRT__NO_INLINE. We want is always inline, so 
__forceinline seems more appropriate and that's what other similar 
functions do. Since commit more 6680efafce500453a68276108d166c034eb8dc53 
other functions should probably use it as well, I will send a new patch.



Also it gets rid of a difference between UCRT and other crts, which is 
always nice.



Jacek



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

[Mingw-w64-public] [PATCH 2/2] crt: Use importlibs for execv* functions.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am   |  2 +-
 mingw-w64-crt/misc/execv.c  |  6 --
 mingw-w64-crt/misc/execve.c |  6 --
 mingw-w64-crt/misc/execvp.c |  6 --
 mingw-w64-crt/misc/execvpe.c|  6 --
 mingw-w64-headers/crt/process.h | 16 
 6 files changed, 9 insertions(+), 33 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/execv.c
 delete mode 100644 mingw-w64-crt/misc/execve.c
 delete mode 100644 mingw-w64-crt/misc/execvp.c
 delete mode 100644 mingw-w64-crt/misc/execvpe.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 9aeb3db3..a30c890e 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -318,7 +318,7 @@ src_libmingwex=\
   misc/alarm.c \
   misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
   misc/delayimp.cmisc/dirent.c  \
-  misc/dirname.c misc/execv.c   misc/execve.c   misc/execvp.cmisc/execvpe.c \
+  misc/dirname.c \
   misc/feclearexcept.c   misc/fegetenv.cmisc/fegetexceptflag.c  misc/fegetround.cmisc/feholdexcept.c\
   misc/feraiseexcept.c   misc/fesetenv.cmisc/fesetexceptflag.c  misc/fesetround.cmisc/fetestexcept.c\
   misc/feupdateenv.c misc/ftruncate.c   misc/fwide.cmisc/getlogin.c  misc/getopt.c  \
diff --git a/mingw-w64-crt/misc/execv.c b/mingw-w64-crt/misc/execv.c
deleted file mode 100644
index 50fd2324..
--- a/mingw-w64-crt/misc/execv.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-int __cdecl execv(const char *_Filename,char *const _ArgList[])
-{
-  return _execv (_Filename, (const char *const *)_ArgList);
-}
diff --git a/mingw-w64-crt/misc/execve.c b/mingw-w64-crt/misc/execve.c
deleted file mode 100644
index 6ab039ea..
--- a/mingw-w64-crt/misc/execve.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-int __cdecl execve(const char *_Filename,char *const _ArgList[],char *const _Env[])
-{
-  return _execve (_Filename, (const char *const *)_ArgList, (const char * const *)_Env);
-}
diff --git a/mingw-w64-crt/misc/execvp.c b/mingw-w64-crt/misc/execvp.c
deleted file mode 100644
index b11ab3f4..
--- a/mingw-w64-crt/misc/execvp.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-int __cdecl execvp(const char *_Filename,char *const _ArgList[])
-{
-  return _execvp (_Filename, (const char *const *)_ArgList);
-}
diff --git a/mingw-w64-crt/misc/execvpe.c b/mingw-w64-crt/misc/execvpe.c
deleted file mode 100644
index f6fa80ad..
--- a/mingw-w64-crt/misc/execvpe.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-int __cdecl execvpe(const char *_Filename,char *const _ArgList[],char *const _Env[])
-{
-  return _execvpe (_Filename, (const char *const *)_ArgList, (const char *const *)_Env);
-}
diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index e4abff94..90775482 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -180,15 +180,15 @@ extern "C" {
  stupid warnings, define them in POSIX way.  This is save, because those
  methods do not return in success case, so that the return value is not
  really dependent to its scalar width.  */
-  int __cdecl execv(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  int __cdecl execve(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  int __cdecl execvp(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  int __cdecl execvpe(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP int __cdecl execv(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP int __cdecl execve(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP int __cdecl execvp(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP int __cdecl execvpe(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
 #else
-  intptr_t __cdecl execv(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  intptr_t __cdecl execve(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  intptr_t __cdecl execvp(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  intptr_t __cdecl execvpe(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP intptr_t __cdecl execv(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP intptr_t __cdecl execve(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;

[Mingw-w64-public] [PATCH 1/2] crt: Use importlibs for difftime* functions.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am  |  2 +-
 mingw-w64-crt/lib-common/msvcrt.def.in |  4 ++--
 mingw-w64-crt/lib32/msvcr100.def.in|  4 ++--
 mingw-w64-crt/lib32/msvcr80.def.in |  2 ++
 mingw-w64-crt/lib32/msvcr90.def.in |  4 ++--
 mingw-w64-crt/lib64/msvcr100.def.in|  4 ++--
 mingw-w64-crt/lib64/msvcr80.def.in |  2 ++
 mingw-w64-crt/lib64/msvcr90.def.in |  4 ++--
 mingw-w64-crt/misc/difftime.c  | 21 -
 mingw-w64-crt/misc/difftime32.c|  9 -
 mingw-w64-crt/misc/difftime64.c|  9 -
 mingw-w64-headers/crt/time.h   | 10 --
 12 files changed, 19 insertions(+), 56 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/difftime.c
 delete mode 100644 mingw-w64-crt/misc/difftime32.c
 delete mode 100644 mingw-w64-crt/misc/difftime64.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 71f19aea..9aeb3db3 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -317,7 +317,7 @@ src_libmingwex=\
   misc/mingw_getsp.S \
   misc/alarm.c \
   misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
-  misc/delayimp.cmisc/difftime.cmisc/difftime32.c   misc/difftime64.cmisc/dirent.c  \
+  misc/delayimp.cmisc/dirent.c  \
   misc/dirname.c misc/execv.c   misc/execve.c   misc/execvp.cmisc/execvpe.c \
   misc/feclearexcept.c   misc/fegetenv.cmisc/fegetexceptflag.c  misc/fegetround.cmisc/feholdexcept.c\
   misc/feraiseexcept.c   misc/fesetenv.cmisc/fesetexceptflag.c  misc/fesetround.cmisc/fetestexcept.c\
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index bc9c0c63..1c4f4089 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -456,8 +456,8 @@ _cwscanf_s
 _cwscanf_s_l
 _dstbias DATA
 F_ARM_ANY(_daylight DATA)
-F_ARM_ANY(_difftime32)
-F_ARM_ANY(_difftime64)
+_difftime32 F_I386(== difftime)
+_difftime64
 _dup
 _dup2
 _ecvt
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in b/mingw-w64-crt/lib32/msvcr100.def.in
index e58937d4..8bc4f514 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -805,8 +805,8 @@ _cwscanf
 _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in b/mingw-w64-crt/lib32/msvcr80.def.in
index 4914931d..c1092e83 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -141,6 +141,8 @@ _creat
 _cscanf
 _ctype DATA
 _cwait
+_difftime32
+_difftime64
 _dstbias DATA
 _dup
 _dup2
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in b/mingw-w64-crt/lib32/msvcr90.def.in
index 182ec506..ada4f638 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -431,8 +431,8 @@ _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
 _decode_pointer DATA
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in b/mingw-w64-crt/lib64/msvcr100.def.in
index c081fea2..5faa3619 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -763,8 +763,8 @@ _cwscanf
 _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in b/mingw-w64-crt/lib64/msvcr80.def.in
index 8b900603..6c6a5518 100644
--- a/mingw-w64-crt/lib64/msvcr80.def.in
+++ b/mingw-w64-crt/lib64/msvcr80.def.in
@@ -231,6 +231,8 @@ _ctype
 _cwait
 _cwprintf
 _cwscanf
+_difftime32
+_difftime64
 _dstbias DATA
 _dup
 _dup2
diff --git a/mingw-w64-crt/lib64/msvcr90.def.in b/mingw-w64-crt/lib64/msvcr90.def.in
index 2ff5050b..14923195 100644
--- a/mingw-w64-crt/lib64/msvcr90.def.in
+++ b/mingw-w64-crt/lib64/msvcr90.def.in
@@ -379,8 +379,8 @@ _cwscanf_l
 _cwscanf_s
 _cwscanf_s_l
 _decode_pointer DATA
-_difftime32 DATA
-_difftime64 DATA
+_difftime32
+_difftime64
 _dosmaperr
 _dstbias DATA
 _dup
diff --git a/mingw-w64-crt/misc/difftime.c b/mingw-w64-crt/misc/difftime.c
deleted file mode 100644
index 5d49f529..
--- a/mingw-w64-crt/misc/difftime.c
+++ /dev/null
@@ -1,21 +0,0 @@
-#define __CRT__NO_INLINE
-#include 
-#include 
-
-/* FIXME: Relying on _USE_32BIT_TIME_T, which is a user-macro,
-during CRT compilation is plainly broken.  Need an appropriate
-implementation to provide users the ability of compiling the
-CRT only with 32-bit time_t behavior. */
-
-#ifndef _USE_32BIT_TIME_T
-double __cdecl difftime(time_t _Time1,time_t _Time2)
-{
-  return _difftime64(_Time1,_Time2);
-}
-#else
-double __cdecl difftime(time_t _Time1,time_t _Time2)
-{
-  return _difftime32(_Time1

[Mingw-w64-public] [PATCH] crt: Get rid of spawnv* forwards in mingwex.

[Jacek Caban]

Those are handled by importlibs already.

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am   | 4 ++--
 mingw-w64-crt/misc/spawnv.c | 6 --
 mingw-w64-crt/misc/spawnve.c| 6 --
 mingw-w64-crt/misc/spawnvp.c| 6 --
 mingw-w64-crt/misc/spawnvpe.c   | 6 --
 mingw-w64-headers/crt/process.h | 8 
 6 files changed, 6 insertions(+), 30 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/spawnv.c
 delete mode 100644 mingw-w64-crt/misc/spawnve.c
 delete mode 100644 mingw-w64-crt/misc/spawnvp.c
 delete mode 100644 mingw-w64-crt/misc/spawnvpe.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index bd0a29f9..71f19aea 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -325,8 +325,8 @@ src_libmingwex=\
   misc/gettimeofday.cmisc/imaxabs.c misc/imaxdiv.c  misc/isblank.c   misc/iswblank.c\
   misc/mbrtowc.c misc/mbsinit.c misc/mempcpy.c  misc/mingw-aligned-malloc.c  misc/mingw-fseek.c \
   misc/mingw_matherr.c   misc/mingw_mbwc_convert.c  misc/mingw_usleep.c misc/mingw_wcstod.c  misc/mingw_wcstof.c\
-  misc/mingw_wcstold.c   misc/mkstemp.c misc/seterrno.c misc/sleep.c misc/spawnv.c  \
-  misc/spawnve.c misc/spawnvp.c misc/spawnvpe.c misc/strnlen.c   misc/strsafe.c \
+  misc/mingw_wcstold.c   misc/mkstemp.c misc/seterrno.c misc/sleep.c  \
+  misc/strnlen.c misc/strsafe.c \
   misc/strtoimax.c   misc/strtold.c misc/strtoumax.cmisc/tdelete.c   misc/tfind.c   \
   misc/tsearch.c misc/twalk.c   misc/uchar_c16rtomb.c   misc/uchar_c32rtomb.cmisc/uchar_mbrtoc16.c  \
   misc/uchar_mbrtoc32.c  misc/wcrtomb.c misc/wcsnlen.c  misc/wcstof.c  \
diff --git a/mingw-w64-crt/misc/spawnv.c b/mingw-w64-crt/misc/spawnv.c
deleted file mode 100644
index 88e690c8..
--- a/mingw-w64-crt/misc/spawnv.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-intptr_t __cdecl spawnv(int mode,const char *_Filename,char *const _ArgList[])
-{
-  return _spawnv(mode, _Filename,(const char *const *)_ArgList);
-}
diff --git a/mingw-w64-crt/misc/spawnve.c b/mingw-w64-crt/misc/spawnve.c
deleted file mode 100644
index 8731c33a..
--- a/mingw-w64-crt/misc/spawnve.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-intptr_t __cdecl spawnve(int mode,const char *_Filename,char *const _ArgList[],char *const _Env[])
-{
-  return _spawnve(mode, _Filename,(const char *const *)_ArgList,(const char *const *)_Env);
-}
diff --git a/mingw-w64-crt/misc/spawnvp.c b/mingw-w64-crt/misc/spawnvp.c
deleted file mode 100644
index 75e17e13..
--- a/mingw-w64-crt/misc/spawnvp.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-intptr_t __cdecl spawnvp(int mode,const char *_Filename,char *const _ArgList[])
-{
-  return _spawnvp(mode, _Filename,(const char *const *)_ArgList);
-}
diff --git a/mingw-w64-crt/misc/spawnvpe.c b/mingw-w64-crt/misc/spawnvpe.c
deleted file mode 100644
index 08e41e82..
--- a/mingw-w64-crt/misc/spawnvpe.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include 
-
-intptr_t __cdecl spawnvpe(int mode,const char *_Filename,char *const _ArgList[],char *const _Env[])
-{
-  return _spawnvpe(mode, _Filename,(const char *const *)_ArgList,(const char *const *)_Env);
-}
diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index bf1004ed..e4abff94 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -190,10 +190,10 @@ extern "C" {
   intptr_t __cdecl execvp(const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
   intptr_t __cdecl execvpe(const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
 #endif
-  intptr_t __cdecl spawnv(int,const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  intptr_t __cdecl spawnve(int,const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  intptr_t __cdecl spawnvp(int,const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-  intptr_t __cdecl spawnvpe(int,const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP intptr_t __cdecl spawnv(int,const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP intptr_t __cdecl spawnve(int,const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP intptr_t __cdecl spawnvp(int,const char *_Filename,char *const _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+  _CRTIMP intptr_t __cdecl spawnvpe(int,const char *_Filename,char *const _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
 #endif
 
 #ifdef _

[Mingw-w64-public] [PATCH] mfobjects.idl: Add missing MFVideoTransferMatrix entries.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/include/mfobjects.idl | 2 ++
 1 file changed, 2 insertions(+)


diff --git a/mingw-w64-headers/include/mfobjects.idl b/mingw-w64-headers/include/mfobjects.idl
index 2fafc070..82462ff4 100644
--- a/mingw-w64-headers/include/mfobjects.idl
+++ b/mingw-w64-headers/include/mfobjects.idl
@@ -279,6 +279,8 @@ typedef enum _MFVideoTransferMatrix {
   MFVideoTransferMatrix_BT709 = 1,
   MFVideoTransferMatrix_BT601 = 2,
   MFVideoTransferMatrix_SMPTE240M = 3,
+  MFVideoTransferMatrix_BT2020_10 = 4,
+  MFVideoTransferMatrix_BT2020_12 = 5,
   MFVideoTransferMatrix_Last,
   MFVideoTransferMatrix_ForceDWORD = 0x7fff
 } MFVideoTransferMatrix;

___
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 v2] crt: Use importlibs for longjmp.

[Jacek Caban]

On 4/3/19 1:51 PM, Martin Storsjö wrote:

On Wed, 3 Apr 2019, Jacek Caban wrote:


Hello,

This version addresses issues found by Martin and applies on top of 
his setjmp patch.


Jacek

Signed-off-by: Jacek Caban 
---


LGTM, please go ahead (and please push my setjmp patch at the same 
time). I test built this together with my headers patch, both with 
msvcrt and ucrt, and it builds and runs fine on all 4 arches. 



Thanks! I pushed both patches.


Jacek



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

[Mingw-w64-public] [PATCH v2] crt: Use importlibs for longjmp.

[Jacek Caban]

Hello,

This version addresses issues found by Martin and applies on top of his 
setjmp patch.


Jacek

Signed-off-by: Jacek Caban 
---

 .../def-include/msvcrt-common.def.in  |  4 ++--
 .../api-ms-win-crt-private-l1-1-0.def.in  |  2 +-
 mingw-w64-crt/lib-common/msvcrt.def.in|  1 -
 mingw-w64-crt/lib-common/ucrtbase.def.in  |  1 -
 .../lib-common/vcruntime140_app.def.in|  2 +-
 mingw-w64-crt/lib32/crtdll.def|  2 +-
 mingw-w64-crt/lib64/ntdllcrt.def  |  2 +-
 mingw-w64-crt/misc/longjmp.S  | 23 ---
 mingw-w64-headers/crt/setjmp.h|  6 ++---
 9 files changed, 9 insertions(+), 34 deletions(-)


diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 364e4409..a98f8a18 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -131,6 +131,8 @@ ADD_UNDERSCORE(hypot)
 ;logb
 ADD_UNDERSCORE(nextafter)
 
+longjmp
+
 #ifndef UCRTBASE
 _daylight DATA
 _timezone DATA
@@ -140,6 +142,4 @@ ADD_UNDERSCORE(timezone)
 ADD_UNDERSCORE(tzname)
 
 ADD_UNDERSCORE(vsnprintf_s)
-
-longjmp DATA
 #endif
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in b/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
index 67e0e1a8..669638b9 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
@@ -1158,7 +1158,7 @@ F_I386(_seh_longjmp_unwind4@4)
 _set_purecall_handler
 _set_se_translator
 F_I386(_setjmp3)
-longjmp F_X86_ANY(DATA)
+longjmp
 memchr
 memcmp
 memcpy
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index 22e75532..bc9c0c63 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -1414,7 +1414,6 @@ log F_X86_ANY(DATA)
 log10
 F_NON_I386(log10f F_X86_ANY(DATA))
 F_NON_I386(logf F_X86_ANY(DATA))
-F_ARM_ANY(longjmp)
 malloc
 mblen
 F_ARM_ANY(mbrlen)
diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in
index beee3dde..49a55521 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -2431,7 +2431,6 @@ logb
 logbf
 logbl
 F_NON_I386(logf F_X86_ANY(DATA))
-longjmp F_X86_ANY(DATA)
 lrint
 lrintf
 lrintl
diff --git a/mingw-w64-crt/lib-common/vcruntime140_app.def.in b/mingw-w64-crt/lib-common/vcruntime140_app.def.in
index 27f79bd4..3ad3e51a 100644
--- a/mingw-w64-crt/lib-common/vcruntime140_app.def.in
+++ b/mingw-w64-crt/lib-common/vcruntime140_app.def.in
@@ -80,7 +80,7 @@ F_I386(_seh_longjmp_unwind@4)
 _set_purecall_handler
 _set_se_translator
 F_I386(_setjmp3)
-longjmp F_X86_ANY(DATA)
+longjmp
 memchr
 memcmp
 memcpy
diff --git a/mingw-w64-crt/lib32/crtdll.def b/mingw-w64-crt/lib32/crtdll.def
index 18aeb0bf..1b330686 100644
--- a/mingw-w64-crt/lib32/crtdll.def
+++ b/mingw-w64-crt/lib32/crtdll.def
@@ -599,7 +599,7 @@ localtime DATA
 ;_localtime32 = localtime
 log
 log10
-longjmp DATA
+longjmp
 malloc
 mblen
 mbstowcs
diff --git a/mingw-w64-crt/lib64/ntdllcrt.def b/mingw-w64-crt/lib64/ntdllcrt.def
index 679a79be..4a7402c2 100644
--- a/mingw-w64-crt/lib64/ntdllcrt.def
+++ b/mingw-w64-crt/lib64/ntdllcrt.def
@@ -118,7 +118,7 @@ iswxdigit
 isxdigit
 labs
 log
-longjmp DATA
+longjmp
 mbstowcs
 memchr
 memcmp
diff --git a/mingw-w64-crt/misc/longjmp.S b/mingw-w64-crt/misc/longjmp.S
index e3a13453..bec0ae15 100644
--- a/mingw-w64-crt/misc/longjmp.S
+++ b/mingw-w64-crt/misc/longjmp.S
@@ -5,29 +5,6 @@
  */
 #include <_mingw_mac.h>
 
-/* 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__) || defined(_ARM64_) || defined(__aarch64__))
-	.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__)) */
-
 #if defined(_ARM_) || defined(__arm__) || defined(_ARM64_) || defined(__aarch64__)
 	.globl __MINGW_USYMBOL(__mingw_setjmp)
 	.def	__MINGW_USYMBOL(__mingw_setjmp);	.scl	2;	.type	32;	.endef
diff --git a/mingw-w64-headers/crt/setjmp.h b/mingw-w64-headers/crt/setjmp.h
index 547dfde2..9f461647 100644
--- a/mingw-w64-headers/crt/setjmp.h
+++ b/mingw-w64-headers/crt/setjmp.h
@@ -200,6 +200,8 @@ extern "C" {
 #define _JMP_BUF_DEFINED
 #endif
 
+_CRTIMP __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void __cdecl longjmp(jmp_buf _Buf,int 

Re: [Mingw-w64-public] [PATCH] crt: Use importlibs for longjmp.

[Jacek Caban]

On 4/3/19 8:37 AM, Martin Storsjö wrote:


Another aspect of this patch I didn't think of yesterday:

diff --git a/mingw-w64-headers/crt/setjmp.h 
b/mingw-w64-headers/crt/setjmp.h

index fc79f109..039c93f0 100644
--- a/mingw-w64-headers/crt/setjmp.h
+++ b/mingw-w64-headers/crt/setjmp.h
@@ -252,8 +252,7 @@ void * __cdecl __attribute__ ((__nothrow__)) 
mingw_getsp (void);
   int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) 
setjmp(jmp_buf _Buf);

 #endif

-  __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void __cdecl 
ms_longjmp(jmp_buf _Buf,int _Value)/* throw(...)*/;
-  __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void __cdecl 
longjmp(jmp_buf _Buf,int _Value);
+  _CRTIMP __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void 
__cdecl longjmp(jmp_buf _Buf,int _Value);


 #ifdef __cplusplus
 }


This will break this part of the existing setjmp.h (earlier in the file):

#    elif defined(_ARM_) || defined(__arm__) || defined(_ARM64_) || 
defined(__aarch64__)

#  define setjmp(BUF) __mingw_setjmp((BUF))
#  define longjmp __mingw_longjmp
  int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) 
__mingw_setjmp(jmp_buf _Buf);


Your patch will add the _CRTIMP to the longjmp declaration, while the 
#define changes the delcaration from longjmp into __mingw_longjmp, 
which isn't available as dllimport. 



Good catch, I will send a fixed version.


Thanks,

Jacek



___
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] crt: Use importlibs for longjmp.

[Jacek Caban]

On 4/3/19 10:21 AM, Martin Storsjö wrote:

On Wed, 3 Apr 2019, Martin Storsjö wrote:


On Tue, 2 Apr 2019, Jacek Caban wrote:

I think we could use the imported version for ARM, by making sure we 
pass NULL as the second parameter to the setjmp functions.


I tried to recheck this now, and while this seems to work for UCRT, it 
doesn't seem to work for msvcrt.dll. So given that I think it's safer 
to keep both ARM and ARM64 functions for now. 



Thanks for checking, let's keep it then.


Jacek



___
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] crt: Use importlibs for longjmp.

[Jacek Caban]

On 02/04/2019 22:18, Martin Storsjö wrote:


On Tue, 2 Apr 2019, Jacek Caban wrote:

We currently have pretty useless chunk of assembly in mingwex that 
recently caused problems with Wine mingw builds. The problem is that 
we have longjmp symbol defined in mingwex which in fact forwards the 
call to the imported function on x64 non-SEH and x86. I did some 
digging in git history, but it doesn't explain much about why it's 
needed.


The one thing I'm not sure is non-SEH x64 build. In this case, it 
sets frame stored in jmp_buf to 0 before calling the actual 
implementation. There is absolutely no explanation for it. Maybe it 
was needed at some point for sjlj exception handling? Even if that's 
the case, it would be a pretty broken design. If such nulling is 
needed, it should be done before calling longjmp; intercepting an 
existing function is definitely not the right way to do it. Maybe 
it's not really needed?


And yet another question is, is non-SEH x64 build still something we 
need to care about?


If we still care about non-SEH x64 builds and really need to carry 
this hack, that could be preserved at the cost of complexity. But my 
guess is that we don't need it and that's what this patch does.


Regarding the patch itself, it looks like you're losing the longjmp 
function altogether from msvcrt.def.in, instead of making it available 
for all arches?



No, that was intentional, note that it's defined in 
msvcrt-common.def.in. Now that I read it again, ucrtbase.def.in could 
also be tweaked to use the version from msvcrt-common.def.in, I will 
send a new version tomorrow.





I believe the reason for clearing the frame field of jmp_buf, is that 
the msvcrt setjmp/longjmp actually does unwinding with SEH, instead of 
just restoring the stored context from jmp_buf. The exact details of 
this seems to differ a bit between architectures (and potentially 
between msvcrt versions).


When doing the setjmp, setjmp is expanded into _setjmp (or a variation 
thereof), where the second parameter is a pointer to the current stack 
frame. When doing longjmp, it does a SEH unwind of the stack until it 
finds a frame that matches this pointer. This parameter afaik is 
stored in the frame field of jmp_buf.


What actually happens if SEH information is unavailable varies quite a 
bit. When testing on ARM and ARM64, the longjmp will crash if SEH is 
unavailable, when _setjmpex is called with a non-null frame pointer. 
On ARM, if the second parameter to _setjmpex is NULL though, the 
longjmp does succeed, but on ARM64 this doesn't help, SEH information 
simply is mandatory. (And for ARM64, the exact form of the frame 
pointer needed is a bit more tricky; llvm had to add a new intrinsic 
function for getting it.)


Given this, it seems like the clearing of the frame field is to make 
sure that the longjmp works as a plain longjmp without SEH unwinding 
(like it worked for me on ARM, unlike ARM64). However, I just tested 
building a toolchain with SJLJ, i.e. without SEH, for x86_64, and 
setjmp/longjmp does seem to work (on Windows 10 18.09, with ucrt) even 
if the frame pointer is left non-null. In this case, the executable 
contained no SEH information altogether. But in a more mixed build, 
where the executable does contain some SEH information (but 
incomplete, unable to do the unwind using it), things fail unless the 
field is cleared.



Thank you for the great explanation! It makes perfect sense now.




However, instead of intercepting the longjmp function, it's probably 
better to just pass NULL for this parameter to begin with, if SEH 
isn't available. With the attached patch, this seems to work fine for me.


So in general, I'd still like to keep x86_64 builds without SEH 
usable. (For llvm-mingw, this was the only configuration of x86_64 up 
until last summer.) But with the patch I just sent, your patch should 
be fine (modulo the misedit in msvcrt.def.in).



Agreed. Your patch is a nice way for supporting that, it looks good to me.


While we're on this subject, is there a reason for providing our own 
implementation for ARM? Could we use imported version as well?



Thanks,

Jacek



___
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] crt/lib-common/msvcrt.def.in: Make `_futime32()` available on x86 and x64.

[Jacek Caban]

On 4/2/19 4:51 PM, Liu Hao wrote:

在 2019/4/2 22:33, Jacek Caban 写道:

On 4/2/19 4:22 PM, Liu Hao wrote:

Personally I'm tempted to say that it's not of interest, but I think
it's still officially supported.


Anyway, in this case supporting XP should be as trivial as forwarding
_futime32 to _futime in .def file.


Jacek

Hmmm but how about Windows XP x64 ?

New patch attached.



Looks good to me.


Thanks,

Jacek



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

Re: [Mingw-w64-public] [PATCH] crt/lib-common/msvcrt.def.in: Make `_futime32()` available on x86 and x64.

[Jacek Caban]

On 4/2/19 4:22 PM, Liu Hao wrote:

Reference: https://sourceforge.net/p/msys2/mailman/message/36628134/
Signed-off-by: Liu Hao 


This apparently reverts modification of this function in
1035bed24e833ea5eb487c78f4f350ea48f31e8b.  Is Windows XP still of
interest today?



Personally I'm tempted to say that it's not of interest, but I think 
it's still officially supported.



Anyway, in this case supporting XP should be as trivial as forwarding 
_futime32 to _futime in .def file.



Jacek



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

[Mingw-w64-public] [PATCH] crt: Use importlibs for longjmp.

[Jacek Caban]

Hello,

We currently have pretty useless chunk of assembly in mingwex that 
recently caused problems with Wine mingw builds. The problem is that we 
have longjmp symbol defined in mingwex which in fact forwards the call 
to the imported function on x64 non-SEH and x86. I did some digging in 
git history, but it doesn't explain much about why it's needed.


The one thing I'm not sure is non-SEH x64 build. In this case, it sets 
frame stored in jmp_buf to 0 before calling the actual implementation. 
There is absolutely no explanation for it. Maybe it was needed at some 
point for sjlj exception handling? Even if that's the case, it would be 
a pretty broken design. If such nulling is needed, it should be done 
before calling longjmp; intercepting an existing function is definitely 
not the right way to do it. Maybe it's not really needed?


And yet another question is, is non-SEH x64 build still something we 
need to care about?


If we still care about non-SEH x64 builds and really need to carry this 
hack, that could be preserved at the cost of complexity. But my guess is 
that we don't need it and that's what this patch does.


Jacek

---
 .../def-include/msvcrt-common.def.in  |  2 +-
 .../api-ms-win-crt-private-l1-1-0.def.in  |  2 +-
 mingw-w64-crt/lib-common/msvcrt.def.in|  1 -
 mingw-w64-crt/lib-common/ucrtbase.def.in  |  2 +-
 .../lib-common/vcruntime140_app.def.in|  2 +-
 mingw-w64-crt/lib32/crtdll.def|  2 +-
 mingw-w64-crt/lib64/ntdllcrt.def  |  2 +-
 mingw-w64-crt/misc/longjmp.S  | 23 ---
 mingw-w64-headers/crt/setjmp.h|  3 +--
 9 files changed, 7 insertions(+), 32 deletions(-)


diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 364e4409..d96aeb68 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -141,5 +141,5 @@ ADD_UNDERSCORE(tzname)
 
 ADD_UNDERSCORE(vsnprintf_s)
 
-longjmp DATA
+longjmp
 #endif
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in b/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
index 67e0e1a8..669638b9 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
@@ -1158,7 +1158,7 @@ F_I386(_seh_longjmp_unwind4@4)
 _set_purecall_handler
 _set_se_translator
 F_I386(_setjmp3)
-longjmp F_X86_ANY(DATA)
+longjmp
 memchr
 memcmp
 memcpy
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index b45f3f5a..5ca5325d 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -1413,7 +1413,6 @@ log F_X86_ANY(DATA)
 log10
 F_NON_I386(log10f F_X86_ANY(DATA))
 F_NON_I386(logf F_X86_ANY(DATA))
-F_ARM_ANY(longjmp)
 malloc
 mblen
 F_ARM_ANY(mbrlen)
diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in
index beee3dde..afe24d81 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -2431,7 +2431,7 @@ logb
 logbf
 logbl
 F_NON_I386(logf F_X86_ANY(DATA))
-longjmp F_X86_ANY(DATA)
+longjmp
 lrint
 lrintf
 lrintl
diff --git a/mingw-w64-crt/lib-common/vcruntime140_app.def.in b/mingw-w64-crt/lib-common/vcruntime140_app.def.in
index 27f79bd4..3ad3e51a 100644
--- a/mingw-w64-crt/lib-common/vcruntime140_app.def.in
+++ b/mingw-w64-crt/lib-common/vcruntime140_app.def.in
@@ -80,7 +80,7 @@ F_I386(_seh_longjmp_unwind@4)
 _set_purecall_handler
 _set_se_translator
 F_I386(_setjmp3)
-longjmp F_X86_ANY(DATA)
+longjmp
 memchr
 memcmp
 memcpy
diff --git a/mingw-w64-crt/lib32/crtdll.def b/mingw-w64-crt/lib32/crtdll.def
index 18aeb0bf..1b330686 100644
--- a/mingw-w64-crt/lib32/crtdll.def
+++ b/mingw-w64-crt/lib32/crtdll.def
@@ -599,7 +599,7 @@ localtime DATA
 ;_localtime32 = localtime
 log
 log10
-longjmp DATA
+longjmp
 malloc
 mblen
 mbstowcs
diff --git a/mingw-w64-crt/lib64/ntdllcrt.def b/mingw-w64-crt/lib64/ntdllcrt.def
index 679a79be..4a7402c2 100644
--- a/mingw-w64-crt/lib64/ntdllcrt.def
+++ b/mingw-w64-crt/lib64/ntdllcrt.def
@@ -118,7 +118,7 @@ iswxdigit
 isxdigit
 labs
 log
-longjmp DATA
+longjmp
 mbstowcs
 memchr
 memcmp
diff --git a/mingw-w64-crt/misc/longjmp.S b/mingw-w64-crt/misc/longjmp.S
index e3a13453..bec0ae15 100644
--- a/mingw-w64-crt/misc/longjmp.S
+++ b/mingw-w64-crt/misc/longjmp.S
@@ -5,29 +5,6 @@
  */
 #include <_mingw_mac.h>
 
-/* 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__) || defined(_ARM64_) || defined(__aarch64__))
-	.globl __MINGW_USYMBOL(longjmp)
-	.def	__MINGW_USYMBOL(longjmp);	.scl	2;	.type	32;	.endef

Re: [Mingw-w64-public] [PATCH 2/2] crt: Split mingw_getsp and longjmp into separated files.

[Jacek Caban]

On 4/1/19 4:38 PM, Liu Hao wrote:

在 2019/4/1 22:09, Jacek Caban 写道:

Signed-off-by: Jacek Caban 
---
  mingw-w64-crt/Makefile.am    |   1 +
  mingw-w64-crt/misc/longjmp.S | 128 +++
  mingw-w64-crt/misc/mingw_getsp.S | 122 -
  3 files changed, 129 insertions(+), 122 deletions(-)
  create mode 100644 mingw-w64-crt/misc/longjmp.S






Both patches look good to me. Thanks.



Thanks for review, pushed commits.


Jacek




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

[Mingw-w64-public] [PATCH 1/2] msvcrt.def.in: Fix _CxxThrowException import on x86.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/lib-common/msvcrt.def.in | 3 ++-
 mingw-w64-crt/lib32/msvcr80.def.in | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)


diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index 19f7d929..b45f3f5a 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -226,7 +226,8 @@ _CrtSetReportHook
 _CrtSetReportHook2
 _CrtSetReportMode
 #endif
-_CxxThrowException
+F_I386(_CxxThrowException@8)
+F_NON_I386(_CxxThrowException)
 F_I386(_EH_prolog)
 _Getdays
 _Getmonths
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in b/mingw-w64-crt/lib32/msvcr80.def.in
index 2ad8c488..4914931d 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -19,7 +19,7 @@ _CIsinh
 _CIsqrt
 _CItan
 _CItanh
-_CxxThrowException
+_CxxThrowException@8
 _EH_prolog
 _Getdays
 _Getmonths

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

[Mingw-w64-public] [PATCH 2/2] crt: Split mingw_getsp and longjmp into separated files.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am|   1 +
 mingw-w64-crt/misc/longjmp.S | 128 +++
 mingw-w64-crt/misc/mingw_getsp.S | 122 -
 3 files changed, 129 insertions(+), 122 deletions(-)
 create mode 100644 mingw-w64-crt/misc/longjmp.S


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index e7de216d..bd0a29f9 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -313,6 +313,7 @@ src_libmingwex=\
   math/cephes_emath.h   math/cephes_mconf.h math/fp_consts.h math/abs64.c \
   \
   misc/mb_wc_common.h \
+  misc/longjmp.S \
   misc/mingw_getsp.S \
   misc/alarm.c \
   misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
diff --git a/mingw-w64-crt/misc/longjmp.S b/mingw-w64-crt/misc/longjmp.S
new file mode 100644
index ..e3a13453
--- /dev/null
+++ b/mingw-w64-crt/misc/longjmp.S
@@ -0,0 +1,128 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#include <_mingw_mac.h>
+
+/* 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__) || defined(_ARM64_) || defined(__aarch64__))
+	.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__)) */
+
+#if defined(_ARM_) || defined(__arm__) || defined(_ARM64_) || defined(__aarch64__)
+	.globl __MINGW_USYMBOL(__mingw_setjmp)
+	.def	__MINGW_USYMBOL(__mingw_setjmp);	.scl	2;	.type	32;	.endef
+__MINGW_USYMBOL(__mingw_setjmp):
+#if defined(_ARM_) || defined(__arm__)
+	mov r1,  #0
+	str r1,  [r0]/* jmp_buf->Frame */
+	str r4,  [r0, #0x4]  /* jmp_buf->R4 */
+	str r5,  [r0, #0x8]  /* jmp_buf->R5 */
+	str r6,  [r0, #0xc]  /* jmp_buf->R6 */
+	str r7,  [r0, #0x10] /* jmp_buf->R7 */
+	str r8,  [r0, #0x14] /* jmp_buf->R8 */
+	str r9,  [r0, #0x18] /* jmp_buf->R9 */
+	str r10, [r0, #0x1c] /* jmp_buf->R10 */
+	str r11, [r0, #0x20] /* jmp_buf->R11 */
+	str sp,  [r0, #0x24] /* jmp_buf->Sp */
+	str lr,  [r0, #0x28] /* jmp_buf->Pc */
+	vmrsr2,  fpscr
+	str r2,  [r0, #0x2c] /* jmp_buf->Fpscr */
+	vstrd8,  [r0, #0x30] /* jmp_buf->D[0] */
+	vstrd9,  [r0, #0x38] /* jmp_buf->D[1] */
+	vstrd10, [r0, #0x40] /* jmp_buf->D[2] */
+	vstrd11, [r0, #0x48] /* jmp_buf->D[3] */
+	vstrd12, [r0, #0x50] /* jmp_buf->D[4] */
+	vstrd13, [r0, #0x58] /* jmp_buf->D[5] */
+	vstrd14, [r0, #0x60] /* jmp_buf->D[6] */
+	vstrd15, [r0, #0x68] /* jmp_buf->D[7] */
+	mov r0,  #0
+	bx  lr
+#elif defined(_ARM64_) || defined(__aarch64__)
+	str xzr, [x0] /* jmp_buf->Frame */
+	stp x19, x20, [x0, #0x10] /* jmp_buf->X19, X20 */
+	stp x21, x22, [x0, #0x20] /* jmp_buf->X21, X22 */
+	stp x23, x24, [x0, #0x30] /* jmp_buf->X23, X24 */
+	stp x25, x26, [x0, #0x40] /* jmp_buf->X25, X26 */
+	stp x27, x28, [x0, #0x50] /* jmp_buf->X27, X28 */
+	stp x29, x30, [x0, #0x60] /* jmp_buf->Fp,  Lr  */
+	mov x2,  sp
+	str x2,   [x0, #0x70] /* jmp_buf->Sp */
+	mrs x2,  fpcr
+	str w2,   [x0, #0x78] /* jmp_buf->Fpcr */
+	mrs x2,  fpsr
+	str w2,   [x0, #0x7c] /* jmp_buf->Fpsr */
+	stp d8,  d9,  [x0, #0x80] /* jmp_buf->D[0-1] */
+	stp d10, d11, [x0, #0x90] /* jmp_buf->D[2-3] */
+	stp d12, d13, [x0, #0xa0] /* jmp_buf->D[4-5] */
+	stp d14, d15, [x0, #0xb0] /* jmp_buf->D[6-7] */
+	mov x0,  #0
+	ret
+#endif
+
+	.globl __MINGW_USYMBOL(__mingw_longjmp)
+	.def	__MINGW_USYMBOL(__mingw_longjmp);	.scl	2;	.type	32;	.endef
+__MINGW_USYMBOL(__mingw_longjmp):
+#if defined(_ARM_) || defined(__arm__)
+	ldr r4,  [r0, #0x4]  /* jmp_buf->R4 */
+	ldr r5,  [r0, #0x8]  /* jmp_buf->R5 */
+	ldr r6,  [r0, #0xc]  /* jmp_buf->R6 */
+	ldr r7,  [r0, #0x10] /* jmp_buf->R7 */
+	ldr r8,  [r0, #0x14] /* jmp_buf->R8 */
+	ldr r9,  [r0, #0x18] /* jmp_buf->R9 */
+	ldr r10, [r0, #0x1c] /* jmp_buf->R10 */
+	ldr r11, [r0, #0x20] /* jmp_buf->R11 */
+	ldr sp,  [r0, #0x24] /* jmp_buf->Sp */
+	ld

Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.

[Jacek Caban]

On 3/29/19 8:26 PM, Martin Storsjö wrote:

On Fri, 29 Mar 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am |  2 +-
.../api-ms-win-crt-runtime-l1-1-0.def.in  |  2 +-
mingw-w64-crt/lib-common/msvcrt.def.in    |  2 +-
mingw-w64-crt/lib-common/ucrtbase.def.in  |  2 +-
mingw-w64-crt/lib32/msvcr100.def.in   |  2 +-
mingw-w64-crt/lib32/msvcr80.def.in    |  2 +-
mingw-w64-crt/lib32/msvcr90.def.in    |  2 +-
mingw-w64-crt/lib32/msvcr90d.def.in   |  2 +-
mingw-w64-crt/lib64/msvcr100.def.in   |  2 +-
mingw-w64-crt/lib64/msvcr80.def.in    |  2 +-
mingw-w64-crt/lib64/msvcr90.def.in    |  2 +-
mingw-w64-crt/lib64/msvcr90d.def.in   |  2 +-
mingw-w64-crt/misc/assert.c   | 31 ---
mingw-w64-headers/crt/assert.h    |  3 +-
14 files changed, 13 insertions(+), 45 deletions(-)
delete mode 100644 mingw-w64-crt/misc/assert.c


LGTM (Do you happen to know why this was this way to begin with? It 
seems to me that this function existed even already in win2k.) 



I don't know, maybe win9x? It has been in the tree since "Add initial 
snapshot of runtime crt." commit and I didn't dig in mingw.org history.



Thanks for the review,

Jacek



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

[Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am |  2 +-
 .../api-ms-win-crt-runtime-l1-1-0.def.in  |  2 +-
 mingw-w64-crt/lib-common/msvcrt.def.in|  2 +-
 mingw-w64-crt/lib-common/ucrtbase.def.in  |  2 +-
 mingw-w64-crt/lib32/msvcr100.def.in   |  2 +-
 mingw-w64-crt/lib32/msvcr80.def.in|  2 +-
 mingw-w64-crt/lib32/msvcr90.def.in|  2 +-
 mingw-w64-crt/lib32/msvcr90d.def.in   |  2 +-
 mingw-w64-crt/lib64/msvcr100.def.in   |  2 +-
 mingw-w64-crt/lib64/msvcr80.def.in|  2 +-
 mingw-w64-crt/lib64/msvcr90.def.in|  2 +-
 mingw-w64-crt/lib64/msvcr90d.def.in   |  2 +-
 mingw-w64-crt/misc/assert.c   | 31 ---
 mingw-w64-headers/crt/assert.h|  3 +-
 14 files changed, 13 insertions(+), 45 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/assert.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index e19beaaf..0af497af 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -314,7 +314,7 @@ src_libmingwex=\
   misc/mb_wc_common.h \
   misc/mingw_getsp.S \
   misc/alarm.c \
-  misc/assert.c  misc/basename.cmisc/btowc.cmisc/delay-f.c   misc/delay-n.c \
+  misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
   misc/delayimp.cmisc/difftime.cmisc/difftime32.c   misc/difftime64.cmisc/dirent.c  \
   misc/dirname.c misc/execv.c   misc/execve.c   misc/execvp.cmisc/execvpe.c \
   misc/feclearexcept.c   misc/fegetenv.cmisc/fegetexceptflag.c  misc/fegetround.cmisc/feholdexcept.c\
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in b/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in
index eb299b86..14db58b6 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in
@@ -24,7 +24,7 @@ __threadid
 __wcserror
 __wcserror_s
 ; DATA set manually
-_assert DATA
+_assert
 _beginthread
 _beginthreadex
 _c_exit
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index 449beb0a..c895523f 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -376,7 +376,7 @@ F_ARM_ANY(_aligned_offset_realloc_dbg)
 _aligned_realloc
 F_ARM_ANY(_aligned_realloc_dbg)
 _amsg_exit
-_assert DATA
+_assert
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in
index d5e7a630..beee3dde 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -203,7 +203,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 ; DATA set manually
-_assert DATA
+_assert
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in b/mingw-w64-crt/lib32/msvcr100.def.in
index 1c6ae3dc..2f01d1b3 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -731,7 +731,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert DATA
+_assert
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in b/mingw-w64-crt/lib32/msvcr80.def.in
index f5e95550..27100fbb 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -111,7 +111,7 @@ _adj_fptan
 _adjust_fdiv DATA
 _aexit_rtn DATA
 _amsg_exit
-_assert DATA
+_assert
 _atodbl
 _atoi64
 _atoldbl
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in b/mingw-w64-crt/lib32/msvcr90.def.in
index c341951a..dbfc80f7 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -356,7 +356,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert DATA
+_assert
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in b/mingw-w64-crt/lib32/msvcr90d.def.in
index 2fe211dd..28a596cb 100644
--- a/mingw-w64-crt/lib32/msvcr90d.def.in
+++ b/mingw-w64-crt/lib32/msvcr90d.def.in
@@ -407,7 +407,7 @@ _aligned_realloc_dbg
 _aligned_recalloc
 _aligned_recalloc_dbg
 _amsg_exit
-_assert DATA
+_assert
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in b/mingw-w64-crt/lib64/msvcr100.def.in
index 68c09d6c..631c581c 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -689,7 +689,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert DATA
+_assert
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in b/mingw-w64-crt/lib64/msvcr80.def.in
index 2372e2e6..bedf55eb 100644
--- a/mingw-w64-crt/lib64/msvcr80.def.in
+++ b/mingw-w64-crt/lib64/msvcr80.def.in
@@ -192,7 +192,7 @@ _aligned_offset_malloc

Re: [Mingw-w64-public] [PATCH v2 1/2] crt: Use importlib for _assert.

[Jacek Caban]

Please ignore that.


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

[Mingw-w64-public] [PATCH v2 1/2] crt: Use importlib for _assert.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am |  2 +-
 .../api-ms-win-crt-runtime-l1-1-0.def.in  |  2 +-
 mingw-w64-crt/lib-common/msvcrt.def.in|  2 +-
 mingw-w64-crt/lib-common/ucrtbase.def.in  |  2 +-
 mingw-w64-crt/lib32/msvcr100.def.in   |  2 +-
 mingw-w64-crt/lib32/msvcr80.def.in|  2 +-
 mingw-w64-crt/lib32/msvcr90.def.in|  2 +-
 mingw-w64-crt/lib32/msvcr90d.def.in   |  2 +-
 mingw-w64-crt/lib64/msvcr100.def.in   |  2 +-
 mingw-w64-crt/lib64/msvcr80.def.in|  2 +-
 mingw-w64-crt/lib64/msvcr90.def.in|  2 +-
 mingw-w64-crt/lib64/msvcr90d.def.in   |  2 +-
 mingw-w64-crt/misc/assert.c   | 31 ---
 mingw-w64-headers/crt/assert.h|  3 +-
 14 files changed, 13 insertions(+), 45 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/assert.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index e19beaaf..0af497af 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -314,7 +314,7 @@ src_libmingwex=\
   misc/mb_wc_common.h \
   misc/mingw_getsp.S \
   misc/alarm.c \
-  misc/assert.c  misc/basename.cmisc/btowc.cmisc/delay-f.c   misc/delay-n.c \
+  misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
   misc/delayimp.cmisc/difftime.cmisc/difftime32.c   misc/difftime64.cmisc/dirent.c  \
   misc/dirname.c misc/execv.c   misc/execve.c   misc/execvp.cmisc/execvpe.c \
   misc/feclearexcept.c   misc/fegetenv.cmisc/fegetexceptflag.c  misc/fegetround.cmisc/feholdexcept.c\
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in b/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in
index eb299b86..365f507b 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in
@@ -24,7 +24,7 @@ __threadid
 __wcserror
 __wcserror_s
 ; DATA set manually
-_assert DATA
+_asserr
 _beginthread
 _beginthreadex
 _c_exit
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index 449beb0a..d75f45ba 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -376,7 +376,7 @@ F_ARM_ANY(_aligned_offset_realloc_dbg)
 _aligned_realloc
 F_ARM_ANY(_aligned_realloc_dbg)
 _amsg_exit
-_assert DATA
+_asserr
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in
index d5e7a630..72dc6af8 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -203,7 +203,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 ; DATA set manually
-_assert DATA
+_asserr
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in b/mingw-w64-crt/lib32/msvcr100.def.in
index 1c6ae3dc..26cded52 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -731,7 +731,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert DATA
+_asserr
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in b/mingw-w64-crt/lib32/msvcr80.def.in
index f5e95550..243da0b3 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -111,7 +111,7 @@ _adj_fptan
 _adjust_fdiv DATA
 _aexit_rtn DATA
 _amsg_exit
-_assert DATA
+_asserr
 _atodbl
 _atoi64
 _atoldbl
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in b/mingw-w64-crt/lib32/msvcr90.def.in
index c341951a..d5907a2a 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -356,7 +356,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert DATA
+_asserr
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in b/mingw-w64-crt/lib32/msvcr90d.def.in
index 2fe211dd..8c7ed546 100644
--- a/mingw-w64-crt/lib32/msvcr90d.def.in
+++ b/mingw-w64-crt/lib32/msvcr90d.def.in
@@ -407,7 +407,7 @@ _aligned_realloc_dbg
 _aligned_recalloc
 _aligned_recalloc_dbg
 _amsg_exit
-_assert DATA
+_asserr
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in b/mingw-w64-crt/lib64/msvcr100.def.in
index 68c09d6c..6e3b9470 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -689,7 +689,7 @@ _aligned_offset_recalloc
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert DATA
+_asserr
 _atodbl
 _atodbl_l
 _atof_l
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in b/mingw-w64-crt/lib64/msvcr80.def.in
index 2372e2e6..c7a1f83f 100644
--- a/mingw-w64-crt/lib64/msvcr80.def.in
+++ b/mingw-w64-crt/lib64/msvcr80.def.in
@@ -192,7 +192,7 @@ _aligned_offset_malloc

Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.

[Jacek Caban]

On 3/29/19 7:47 PM, Martin Storsjö wrote:

On Fri, 29 Mar 2019, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/Makefile.am  |  2 +-
mingw-w64-crt/misc/assert.c    | 31 ---
mingw-w64-headers/crt/assert.h |  3 +--
3 files changed, 2 insertions(+), 34 deletions(-)
delete mode 100644 mingw-w64-crt/misc/assert.c


Shouldn't we remove the DATA markings for _assert in all the crt def 
files here as well? 



Yeah, good catch, I had it in another commit accidentally. I will send a 
new version.



Thanks,

Jacek



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

[Mingw-w64-public] [PATCH 2/2] crt: Use importlib for _wassert.

[Jacek Caban]

It's not available on XP, so we need to provice a compat implementation 
for libmsvcrt-os.a.


Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am  |  5 +-
 mingw-w64-crt/lib-common/msvcrt.def.in |  2 +-
 mingw-w64-crt/lib32/msvcr100.def.in|  2 +-
 mingw-w64-crt/lib32/msvcr80.def.in |  1 +
 mingw-w64-crt/lib32/msvcr90.def.in |  2 +-
 mingw-w64-crt/lib32/msvcr90d.def.in|  2 +-
 mingw-w64-crt/lib64/msvcr100.def.in|  2 +-
 mingw-w64-crt/lib64/msvcr80.def.in |  1 +
 mingw-w64-crt/lib64/msvcr90.def.in |  2 +-
 mingw-w64-crt/lib64/msvcr90d.def.in|  2 +-
 mingw-w64-crt/misc/wassert.c   | 72 +-
 mingw-w64-headers/crt/assert.h |  3 +-
 12 files changed, 49 insertions(+), 47 deletions(-)


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 0af497af..e7de216d 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -231,7 +231,8 @@ src_ucrtbase=\
 
 src_msvcrt32=\
   $(src_msvcrt) \
-  misc/lc_locale_func.c
+  misc/lc_locale_func.c \
+  misc/wassert.c
 
 src_msvcrt64=\
   $(src_msvcrt) \
@@ -327,7 +328,7 @@ src_libmingwex=\
   misc/spawnve.c misc/spawnvp.c misc/spawnvpe.c misc/strnlen.c   misc/strsafe.c \
   misc/strtoimax.c   misc/strtold.c misc/strtoumax.cmisc/tdelete.c   misc/tfind.c   \
   misc/tsearch.c misc/twalk.c   misc/uchar_c16rtomb.c   misc/uchar_c32rtomb.cmisc/uchar_mbrtoc16.c  \
-  misc/uchar_mbrtoc32.c  misc/wassert.c misc/wcrtomb.c  misc/wcsnlen.c   misc/wcstof.c  \
+  misc/uchar_mbrtoc32.c  misc/wcrtomb.c misc/wcsnlen.c  misc/wcstof.c  \
   misc/wcstoimax.c   misc/wcstold.c misc/wcstoumax.cmisc/wctob.c misc/wctrans.c \
   misc/wctype.c  misc/wdirent.c misc/winbs_uint64.c misc/winbs_ulong.c   misc/winbs_ushort.c\
   misc/wmemchr.c misc/wmemcmp.c misc/wmemcpy.c  misc/wmemmove.c  misc/wmempcpy.c\
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in
index 449beb0a..e271d2e3 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -1138,7 +1138,7 @@ _waccess
 ; _waccess_s Replaced by emu
 _wasctime
 ; _wasctime_s Replaced by emu
-F_ARM_ANY(_wassert)
+F_NON_I386(_wassert)
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in b/mingw-w64-crt/lib32/msvcr100.def.in
index 1c6ae3dc..9c149db1 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -1519,7 +1519,7 @@ _waccess
 _waccess_s
 _wasctime
 _wasctime_s
-_wassert DATA
+_wassert
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in b/mingw-w64-crt/lib32/msvcr80.def.in
index f5e95550..d0776d8f 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -800,6 +800,7 @@ _strtoui64
 _ungetwch
 _vscprintf
 _vscwprintf
+_wassert
 _wcserror
 _wcstoi64
 _wcstoui64
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in b/mingw-w64-crt/lib32/msvcr90.def.in
index c341951a..c7e67aea 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -1153,7 +1153,7 @@ _waccess
 _waccess_s
 _wasctime
 _wasctime_s
-_wassert DATA
+_wassert
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in b/mingw-w64-crt/lib32/msvcr90d.def.in
index 2fe211dd..e54acf63 100644
--- a/mingw-w64-crt/lib32/msvcr90d.def.in
+++ b/mingw-w64-crt/lib32/msvcr90d.def.in
@@ -1219,7 +1219,7 @@ _waccess
 _waccess_s
 _wasctime
 _wasctime_s
-_wassert DATA
+_wassert
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in b/mingw-w64-crt/lib64/msvcr100.def.in
index 68c09d6c..48fc5a8d 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -1466,7 +1466,7 @@ _waccess
 _waccess_s
 _wasctime
 _wasctime_s
-_wassert DATA
+_wassert
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in b/mingw-w64-crt/lib64/msvcr80.def.in
index 2372e2e6..7e05606e 100644
--- a/mingw-w64-crt/lib64/msvcr80.def.in
+++ b/mingw-w64-crt/lib64/msvcr80.def.in
@@ -557,6 +557,7 @@ vsnprintf == _vsnprintf
 _vsnwprintf
 _waccess
 _wasctime
+_wassert
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib64/msvcr90.def.in b/mingw-w64-crt/lib64/msvcr90.def.in
index cf01dc0c..ec087968 100644
--- a/mingw-w64-crt/lib64/msvcr90.def.in
+++ b/mingw-w64-crt/lib64/msvcr90.def.in
@@ -1086,7 +1086,7 @@ _waccess
 _waccess_s
 _wasctime
 _wasctime_s
-_wassert DATA
+_wassert
 _wchdir
 _wchmod
 _wcmdln DATA
diff --git a/mingw-w64-crt/lib64/msvcr90d.def.in b/mingw-w64-crt/lib64/msvcr90d.def.in
index 99b167ee..e40b3691 100644
--- a/mingw-w64-crt/lib64/msvcr90d.def.in
+++ b

[Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am  |  2 +-
 mingw-w64-crt/misc/assert.c| 31 ---
 mingw-w64-headers/crt/assert.h |  3 +--
 3 files changed, 2 insertions(+), 34 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/assert.c


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index e19beaaf..0af497af 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -314,7 +314,7 @@ src_libmingwex=\
   misc/mb_wc_common.h \
   misc/mingw_getsp.S \
   misc/alarm.c \
-  misc/assert.c  misc/basename.cmisc/btowc.cmisc/delay-f.c   misc/delay-n.c \
+  misc/basename.cmisc/btowc.c   misc/delay-f.c  misc/delay-n.c \
   misc/delayimp.cmisc/difftime.cmisc/difftime32.c   misc/difftime64.cmisc/dirent.c  \
   misc/dirname.c misc/execv.c   misc/execve.c   misc/execvp.cmisc/execvpe.c \
   misc/feclearexcept.c   misc/fegetenv.cmisc/fegetexceptflag.c  misc/fegetround.cmisc/feholdexcept.c\
diff --git a/mingw-w64-crt/misc/assert.c b/mingw-w64-crt/misc/assert.c
deleted file mode 100644
index 0bebb7e9..
--- a/mingw-w64-crt/misc/assert.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/**
- * This file has no copyright assigned and is placed in the Public Domain.
- * This file is part of the mingw-w64 runtime package.
- * No warranty is given; refer to the file DISCLAIMER.PD within this package.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-void __cdecl _wassert (const wchar_t *, const wchar_t *,unsigned);
-void __cdecl _assert (const char *, const char *, unsigned);
-
-void __cdecl
-_assert (const char *_Message, const char *_File, unsigned _Line)
-{
-  wchar_t *m, *f;
-  int i;
-  m = (wchar_t *) malloc ((strlen (_Message) + 1) * sizeof (wchar_t));
-  f = (wchar_t *) malloc ((strlen (_File) + 1) * sizeof (wchar_t));
-  for (i = 0; _Message[i] != 0; i++)
-m[i] = ((wchar_t) _Message[i]) & 0xff;
-  m[i] = 0;
-  for (i = 0; _File[i] != 0; i++)
-f[i] = ((wchar_t) _File[i]) & 0xff;
-  f[i] = 0;
-  _wassert (m, f, _Line);
-  free (m);
-  free (f);
-}
diff --git a/mingw-w64-headers/crt/assert.h b/mingw-w64-headers/crt/assert.h
index 0d7b1f16..4004a959 100644
--- a/mingw-w64-headers/crt/assert.h
+++ b/mingw-w64-headers/crt/assert.h
@@ -44,8 +44,7 @@ extern "C" {
 
 extern void __cdecl
 _wassert(const wchar_t *_Message,const wchar_t *_File,unsigned _Line);
-extern void __cdecl
-_assert (const char *_Message, const char *_File, unsigned _Line);
+_CRTIMP void __cdecl _assert (const char *_Message, const char *_File, unsigned _Line);
 
 #ifdef __cplusplus
 }

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

[Mingw-w64-public] [PATCH] intsafe.h: Add SizeTToUInt32.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/include/intsafe.h | 1 +
 1 file changed, 1 insertion(+)


diff --git a/mingw-w64-headers/include/intsafe.h b/mingw-w64-headers/include/intsafe.h
index 701d4cef..057c3796 100644
--- a/mingw-w64-headers/include/intsafe.h
+++ b/mingw-w64-headers/include/intsafe.h
@@ -216,6 +216,7 @@ __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(SizeTToPtrdiffT, size_t, ptrdiff_t)
 __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(SizeTToLongPtr, size_t, LONG_PTR)
 __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(SizeTToSSIZET, size_t, SSIZE_T)
 __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(SizeTToInt64, size_t, INT64)
+__MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(SizeTToUInt32, size_t, UINT32)
 __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV_UCHAR(ULongPtrToUChar, ULONG_PTR, UCHAR)
 __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(ULongPtrToUInt8, ULONG_PTR, UINT8)
 __MINGW_INTSAFE_API __MINGW_INTSAFE_CONV(ULongPtrToInt8, ULONG_PTR, INT8)

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

[Mingw-w64-public] [PATCH] libd3dcompiler.a: Default to d3dcompiler_47.dll to match headers.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index c38816e6..e19beaaf 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -70,7 +70,7 @@ d3dx9=d3dx9_43
 d3dx10=d3dx10_43
 d3dx11=d3dx11_43
 d3dcsxd=d3dcsxd_43
-d3dcompiler=d3dcompiler_43
+d3dcompiler=d3dcompiler_47
 
 # can move this into libsrc/dummy_libm.c or similar
 BUILT_SOURCES = _libm_dummy.c
@@ -1129,7 +1129,7 @@ lib64/libd3dx11.a: lib64/$(d3dx11).def
 	$(DTDEF64) $<
 lib64/libd3dcsxd.a: lib64/$(d3dcsxd).def
 	$(DTDEF64) $<
-lib64/libd3dcompiler.a: lib64/$(d3dcompiler).def
+lib64/libd3dcompiler.a: lib-common/$(d3dcompiler).def
 	$(DTDEF64) $<
 
 endif

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