Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-27 Thread Jacek Caban 

On 11/27/18 1:05 AM, Mateusz wrote:

In all documentations about fseeko/fseek that I found it is clear stated that 
fseeko works exactly like fseek but it is better and preferable (because of 
_off_t instead of long). mingw implementation of fseeko64 looks too much 
simplified (it is possible that it was written before _fseeki64).

My question/proposition is:
we declare fseeko64 as
_CRTIMP int __cdecl fseeko64...

for libmsvcrt we add line to fseeki64.c
int __cdecl (*__MINGW_IMP_SYMBOL(fseeko64))(FILE *, _off64_t, int) = _fseeki64;

for libmsvcr90 and newer we add line to def.in file
fseeko64 == _fseeki64
and we delete 'DATA' from original _fseeki64 (libmsvcr90 and 100)

We could do similar for ftello64.

Is that way OK?



I looked it up and it seems that you're right. We shouldn't need a 
separated implementation and forwarding to fseeki64 looks like sensible 
thing to do. (In fact, I don't even know why we have fseeko64 in the 
first place, but removing it now is not an option as there are 
applications depending on us exposing those functions). And yeah, in 
this case moving it into msvcr* libs and using .def files when possible 
seems like the right solution for 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] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-27 Thread Jacek Caban 

On 11/27/18 2:41 PM, Martin Storsjö wrote:

On Tue, 27 Nov 2018, Mateusz wrote:


OK, I've attached minimal version -- inline helpers kept for ucrt, 
only _fseeki64 and _ftelli64 moved, I also removed 'DATA' guards for 
multiple definition in libmsvcr90 and 100.


This version looks fine to me. Jacek? 



Looks good to me as well, I pushed it 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] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-27 Thread Martin Storsjö 

On Tue, 27 Nov 2018, Mateusz wrote:


W dniu 26.11.2018 o 23:30, Jacek Caban pisze:

On 11/26/18 10:31 PM, Martin Storsjö wrote:

On Mon, 26 Nov 2018, Jacek Caban wrote:


Hi Mateusz,


The patch looks mostly good to me.


On 23/11/2018 22:37, Mateusz wrote:

--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
  /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should be 
fine */
    /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* fseeko32 
redirects to fseeko64 */
-#if __MSVCRT_VERSION__ >= 0x1400
+#if __MSVCRT_VERSION__ >= 0x900
    // Mark these as _CRTIMP to avoid trying to link in the mingwex versions.
    _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
    _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
-  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
-    return fseek(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int _Origin) {
-    return _fseeki64(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr _off_t ftello(FILE *_File) {
-    return ftell(_File);
-  }
-  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
-    return _ftelli64(_File);
-  }
  #else
    __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int 
_Origin);
    __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
+#endif


I would suggest to get rid of #if here and simply always use _CRTIMP without 
__MINGW_EXTENSION. This would require adding symbols with __MINGW_IMP_SYMBOL to 
symbols in fseeki64.c.


I'm not quite sure I know all the nuances about the difference between e.g. 
fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their implementation is 
rather different), but... On one hand I'd like to keep inline versions in the 
headers for ucrt, but on the other hand it is unnecessary if the libmingwex 
versions work as well. If others prefer unifying it I don't mind.



Actually I didn't notice that aspect, I concentrated on getting moving part 
right. Before changing that, it would at least deserve a reasoning. I'm not 
sure about nuances as well, so I don't know what's the best solution. I'd 
prefer to simply keep it out of this patch.




In general the patch (the latest version) looks rather straightforward to me, 
and I'm fine with it if Jacek is.



With inline helpers kept for ucrt builds, I will be fine with the patch.


Thanks,

Jacek


OK, I've attached minimal version -- inline helpers kept for ucrt, only 
_fseeki64 and _ftelli64 moved, I also removed 'DATA' guards for multiple 
definition in libmsvcr90 and 100.


This version looks fine to me. Jacek?

// Martin

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

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-27 Thread Mateusz 
W dniu 26.11.2018 o 23:30, Jacek Caban pisze:
> On 11/26/18 10:31 PM, Martin Storsjö wrote:
>> On Mon, 26 Nov 2018, Jacek Caban wrote:
>>
>>> Hi Mateusz,
>>>
>>>
>>> The patch looks mostly good to me.
>>>
>>>
>>> On 23/11/2018 22:37, Mateusz wrote:
 --- a/mingw-w64-headers/crt/stdio.h
 +++ b/mingw-w64-headers/crt/stdio.h
 @@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const 
 char *__format, __builtin_va_li
   /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
 be fine */
     /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* 
 fseeko32 redirects to fseeko64 */
 -#if __MSVCRT_VERSION__ >= 0x1400
 +#if __MSVCRT_VERSION__ >= 0x900
     // Mark these as _CRTIMP to avoid trying to link in the mingwex 
 versions.
     _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
     _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
 -  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) 
 {
 -    return fseek(_File, _Offset, _Origin);
 -  }
 -  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
 _Origin) {
 -    return _fseeki64(_File, _Offset, _Origin);
 -  }
 -  __mingw_static_ovr _off_t ftello(FILE *_File) {
 -    return ftell(_File);
 -  }
 -  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
 -    return _ftelli64(_File);
 -  }
   #else
     __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 
 _Offset,int _Origin);
     __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
 +#endif
>>>
>>> I would suggest to get rid of #if here and simply always use _CRTIMP 
>>> without __MINGW_EXTENSION. This would require adding symbols with 
>>> __MINGW_IMP_SYMBOL to symbols in fseeki64.c.
>>
>> I'm not quite sure I know all the nuances about the difference between e.g. 
>> fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their implementation is 
>> rather different), but... On one hand I'd like to keep inline versions in 
>> the headers for ucrt, but on the other hand it is unnecessary if the 
>> libmingwex versions work as well. If others prefer unifying it I don't mind.
> 
> 
> Actually I didn't notice that aspect, I concentrated on getting moving part 
> right. Before changing that, it would at least deserve a reasoning. I'm not 
> sure about nuances as well, so I don't know what's the best solution. I'd 
> prefer to simply keep it out of this patch.
> 
> 
>>
>> In general the patch (the latest version) looks rather straightforward to 
>> me, and I'm fine with it if Jacek is. 
> 
> 
> With inline helpers kept for ucrt builds, I will be fine with the patch.
> 
> 
> Thanks,
> 
> Jacek

OK, I've attached minimal version -- inline helpers kept for ucrt, only 
_fseeki64 and _ftelli64 moved, I also removed 'DATA' guards for multiple 
definition in libmsvcr90 and 100.

Regards,
Mateusz
From f809876dfa33350d713b465cc033e85095fafddc Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Tue, 27 Nov 2018 09:21:36 +0100
Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to
 libmsvcrt

_fseeki64 and _ftelli64 functions are already in libmsvcr90 and newer,
so we need to provide these functions only for libmsvcrt. In addition,
_ftelli64 function implementation is not compatible with ucrt.

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am   |   1 +
 mingw-w64-crt/lib32/msvcr100.def.in |   4 +-
 mingw-w64-crt/lib32/msvcr90.def.in  |   4 +-
 mingw-w64-crt/lib64/msvcr100.def.in |   4 +-
 mingw-w64-crt/lib64/msvcr90.def.in  |   4 +-
 mingw-w64-crt/stdio/fseeki64.c  | 177 
 mingw-w64-crt/stdio/fseeko64.c  | 131 --
 mingw-w64-headers/crt/stdio.h   |   5 +-
 8 files changed, 187 insertions(+), 143 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/fseeki64.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a..f8b0623 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -210,6 +210,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/fseeki64.c \
   stdio/mingw_lock.c
 
 src_ucrtbase=\
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in 
b/mingw-w64-crt/lib32/msvcr100.def.in
index d103a2b..99a39c9 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -880,7 +880,7 @@ _freefls@4
 _fscanf_l
 _fscanf_s_l
 _fseek_nolock
-_fseeki64 DATA
+_fseeki64
 _fseeki64_nolock
 _fsopen
 _fstat32
@@ -890,7 +890,7 @@ _fstat32i64
 _fstat64
 _fstat64i32
 _ftell_nolock
-_ftelli64 DATA
+_ftelli64
 _ftelli64_nolock
 _ftime32
 _ftime32_s
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in 
b/mingw-w64-crt/lib32/msvcr90.def.in
index 861ce56..a055ce3 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -507,7 +507,7 @@ _freefls@4

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-26 Thread Liu Hao 
在 2018/11/27 上午6:30, Jacek Caban 写道:
> On 11/26/18 10:31 PM, Martin Storsjö wrote:
>>
>> In general the patch (the latest version) looks rather straightforward
>> to me, and I'm fine with it if Jacek is. 
> 
> 
> With inline helpers kept for ucrt builds, I will be fine with the patch.
> 
> 

Please remember to push this patch when appropriate as the OP doesn't
have write access to our repo.

BTW I think we can update our policy so that reviewers shall push
patches, to prevent these patches from being missed under such
circumstances.


-- 
Best regards,
LH_Mouse



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-26 Thread Mateusz 
W dniu 26.11.2018 o 23:30, Jacek Caban pisze:
> On 11/26/18 10:31 PM, Martin Storsjö wrote:
>> On Mon, 26 Nov 2018, Jacek Caban wrote:
>>
>>> Hi Mateusz,
>>>
>>>
>>> The patch looks mostly good to me.
>>>
>>>
>>> On 23/11/2018 22:37, Mateusz wrote:
 --- a/mingw-w64-headers/crt/stdio.h
 +++ b/mingw-w64-headers/crt/stdio.h
 @@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const 
 char *__format, __builtin_va_li
   /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
 be fine */
     /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* 
 fseeko32 redirects to fseeko64 */
 -#if __MSVCRT_VERSION__ >= 0x1400
 +#if __MSVCRT_VERSION__ >= 0x900
     // Mark these as _CRTIMP to avoid trying to link in the mingwex 
 versions.
     _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
     _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
 -  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) 
 {
 -    return fseek(_File, _Offset, _Origin);
 -  }
 -  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
 _Origin) {
 -    return _fseeki64(_File, _Offset, _Origin);
 -  }
 -  __mingw_static_ovr _off_t ftello(FILE *_File) {
 -    return ftell(_File);
 -  }
 -  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
 -    return _ftelli64(_File);
 -  }
   #else
     __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 
 _Offset,int _Origin);
     __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
 +#endif
>>>
>>> I would suggest to get rid of #if here and simply always use _CRTIMP 
>>> without __MINGW_EXTENSION. This would require adding symbols with 
>>> __MINGW_IMP_SYMBOL to symbols in fseeki64.c.
>>
>> I'm not quite sure I know all the nuances about the difference between e.g. 
>> fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their implementation is 
>> rather different), but... On one hand I'd like to keep inline versions in 
>> the headers for ucrt, but on the other hand it is unnecessary if the 
>> libmingwex versions work as well. If others prefer unifying it I don't mind.
> 
> 
> Actually I didn't notice that aspect, I concentrated on getting moving part 
> right. Before changing that, it would at least deserve a reasoning. I'm not 
> sure about nuances as well, so I don't know what's the best solution. I'd 
> prefer to simply keep it out of this patch.
> 
> 
>>
>> In general the patch (the latest version) looks rather straightforward to 
>> me, and I'm fine with it if Jacek is. 
> 
> 
> With inline helpers kept for ucrt builds, I will be fine with the patch.

In all documentations about fseeko/fseek that I found it is clear stated that 
fseeko works exactly like fseek but it is better and preferable (because of 
_off_t instead of long). mingw implementation of fseeko64 looks too much 
simplified (it is possible that it was written before _fseeki64).

My question/proposition is:
we declare fseeko64 as
_CRTIMP int __cdecl fseeko64...

for libmsvcrt we add line to fseeki64.c
int __cdecl (*__MINGW_IMP_SYMBOL(fseeko64))(FILE *, _off64_t, int) = _fseeki64;

for libmsvcr90 and newer we add line to def.in file
fseeko64 == _fseeki64
and we delete 'DATA' from original _fseeki64 (libmsvcr90 and 100)

We could do similar for ftello64.

Is that way OK?

Regards,
Mateusz



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

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-26 Thread Jacek Caban 

On 11/26/18 10:31 PM, Martin Storsjö wrote:

On Mon, 26 Nov 2018, Jacek Caban wrote:


Hi Mateusz,


The patch looks mostly good to me.


On 23/11/2018 22:37, Mateusz wrote:

--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, 
const char *__format, __builtin_va_li
  /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting 
should be fine */
    /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* 
fseeko32 redirects to fseeko64 */

-#if __MSVCRT_VERSION__ >= 0x1400
+#if __MSVCRT_VERSION__ >= 0x900
    // Mark these as _CRTIMP to avoid trying to link in the mingwex 
versions.
    _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int 
_Origin);

    _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
-  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int 
_Origin) {

-    return fseek(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, 
int _Origin) {

-    return _fseeki64(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr _off_t ftello(FILE *_File) {
-    return ftell(_File);
-  }
-  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
-    return _ftelli64(_File);
-  }
  #else
    __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 
_Offset,int _Origin);

    __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
+#endif


I would suggest to get rid of #if here and simply always use _CRTIMP 
without __MINGW_EXTENSION. This would require adding symbols with 
__MINGW_IMP_SYMBOL to symbols in fseeki64.c.


I'm not quite sure I know all the nuances about the difference between 
e.g. fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their 
implementation is rather different), but... On one hand I'd like to 
keep inline versions in the headers for ucrt, but on the other hand it 
is unnecessary if the libmingwex versions work as well. If others 
prefer unifying it I don't mind.



Actually I didn't notice that aspect, I concentrated on getting moving 
part right. Before changing that, it would at least deserve a reasoning. 
I'm not sure about nuances as well, so I don't know what's the best 
solution. I'd prefer to simply keep it out of this patch.





In general the patch (the latest version) looks rather straightforward 
to me, and I'm fine with it if Jacek is. 



With inline helpers kept for ucrt builds, I will be fine with the patch.


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] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-26 Thread Martin Storsjö 

On Mon, 26 Nov 2018, Jacek Caban wrote:


Hi Mateusz,


The patch looks mostly good to me.


On 23/11/2018 22:37, Mateusz wrote:

--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
  /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
be fine */
/* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* fseeko32 
redirects to fseeko64 */

-#if __MSVCRT_VERSION__ >= 0x1400
+#if __MSVCRT_VERSION__ >= 0x900
// Mark these as _CRTIMP to avoid trying to link in the mingwex 
versions.

_CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
_CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
-  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) 
{

-return fseek(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
_Origin) {

-return _fseeki64(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr _off_t ftello(FILE *_File) {
-return ftell(_File);
-  }
-  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
-return _ftelli64(_File);
-  }
  #else
__MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int 
_Origin);

__MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
+#endif


I would suggest to get rid of #if here and simply always use _CRTIMP without 
__MINGW_EXTENSION. This would require adding symbols with __MINGW_IMP_SYMBOL 
to symbols in fseeki64.c.


I'm not quite sure I know all the nuances about the difference between 
e.g. fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their 
implementation is rather different), but... On one hand I'd like to keep 
inline versions in the headers for ucrt, but on the other hand it is 
unnecessary if the libmingwex versions work as well. If others prefer 
unifying it I don't mind.


In general the patch (the latest version) looks rather straightforward to 
me, and I'm fine with it if Jacek is.


// Martin



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

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-26 Thread Mateusz 
W dniu 26.11.2018 o 12:36, Jacek Caban pisze:
> Hi Mateusz,
> 
> 
> The patch looks mostly good to me.
> 
> 
> On 23/11/2018 22:37, Mateusz wrote:
>> --- a/mingw-w64-headers/crt/stdio.h
>> +++ b/mingw-w64-headers/crt/stdio.h
>> @@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const char 
>> *__format, __builtin_va_li
>>       /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
>> be fine */
>>     /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* fseeko32 
>> redirects to fseeko64 */
>> -#if __MSVCRT_VERSION__ >= 0x1400
>> +#if __MSVCRT_VERSION__ >= 0x900
>>     // Mark these as _CRTIMP to avoid trying to link in the mingwex versions.
>>     _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
>>     _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
>> -  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
>> -    return fseek(_File, _Offset, _Origin);
>> -  }
>> -  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
>> _Origin) {
>> -    return _fseeki64(_File, _Offset, _Origin);
>> -  }
>> -  __mingw_static_ovr _off_t ftello(FILE *_File) {
>> -    return ftell(_File);
>> -  }
>> -  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
>> -    return _ftelli64(_File);
>> -  }
>>   #else
>>     __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int 
>> _Origin);
>>     __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
>> +#endif
> 
> I would suggest to get rid of #if here and simply always use _CRTIMP without 
> __MINGW_EXTENSION. This would require adding symbols with __MINGW_IMP_SYMBOL 
> to symbols in fseeki64.c.

Thanks for the suggestion -- new patch attached with __MINGW_IMP_SYMBOL.

I decided to not remove mingw_dosmaperr function -- it is safer and I found in 
some project the code:
#ifndef WIN_32
#define _dosmaperr mingw_dosmaperr

There is a problem with libmsvcr80 -- it is not working for me at all, error 
output from CMake:
  The C compiler

"F:/MSYS/m64-731/bin/gcc.exe"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir: F:/x265/ma/12-b/CMakeFiles/CMakeTmp

Run Build Command:"F:/MSYS/bin/make.exe" "cmTC_1e936/fast"
/usr/bin/make -f CMakeFiles/cmTC_1e936.dir/build.make 
CMakeFiles/cmTC_1e936.dir/build
make[1]: Entering directory `/f/x265/ma/12-b/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_1e936.dir/testCCompiler.c.obj
/F/MSYS/m64-731/bin/gcc.exe-o 
CMakeFiles/cmTC_1e936.dir/testCCompiler.c.obj   -c 
/F/x265/ma/12-b/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_1e936.exe
/F/cmake/bin/cmake.exe -E remove -f CMakeFiles/cmTC_1e936.dir/objects.a
/F/MSYS/m64-731/bin/ar.exe cr CMakeFiles/cmTC_1e936.dir/objects.a 
@CMakeFiles/cmTC_1e936.dir/objects1.rsp
/F/MSYS/m64-731/bin/gcc.exe  -Wl,--whole-archive 
CMakeFiles/cmTC_1e936.dir/objects.a -Wl,--no-whole-archive  -o cmTC_1e936.exe 
-Wl,--out-implib,libcmTC_1e936.dll.a 
-Wl,--major-image-version,0,--minor-image-version,0 
@CMakeFiles/cmTC_1e936.dir/linklibs.rsp

f:/msys/m64-731/bin/../lib/gcc/x86_64-w64-mingw32/7.3.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
f:/msys/m64-731/bin/../lib/gcc/x86_64-w64-mingw32/7.3.1/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.text+0x270):
 undefined reference to `_set_invalid_parameter_handler'
collect2.exe: error: ld returned 1 exit status

I decide to not touch libmsvcr80 at all, because it is not working.

Regards,
Mateusz
From 7ffedc542531e01cc76242ff96c6b96593779a26 Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Mon, 26 Nov 2018 20:17:22 +0100
Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to
 libmsvcrt

_fseeki64 and _ftelli64 functions are already in libmsvcr90 and newer,
so we need to provide these functions only for libmsvcrt. In addition,
_ftelli64 function implementation is not compatible with ucrt.

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am  |   1 +
 mingw-w64-crt/stdio/fseeki64.c | 175 +
 mingw-w64-crt/stdio/fseeko64.c | 131 --
 mingw-w64-headers/crt/stdio.h  |  18 -
 4 files changed, 176 insertions(+), 149 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/fseeki64.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a..f8b0623 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -210,6 +210,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/fseeki64.c \
   stdio/mingw_lock.c
 
 src_ucrtbase=\
diff --git a/mingw-w64-crt/stdio/fseeki64.c b/mingw-w64-crt/stdio/fseeki64.c
new file mode 100644
index 000..fbf7f4c
--- /dev/null
+++ b/mingw-w64-crt/stdio/fseeki64.c
@@ -0,0 +1,175 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-26 Thread Jacek Caban 

Hi Mateusz,


The patch looks mostly good to me.


On 23/11/2018 22:37, Mateusz wrote:

--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
  
/* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should be fine */

/* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* fseeko32 
redirects to fseeko64 */
-#if __MSVCRT_VERSION__ >= 0x1400
+#if __MSVCRT_VERSION__ >= 0x900
// Mark these as _CRTIMP to avoid trying to link in the mingwex versions.
_CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
_CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
-  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
-return fseek(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int _Origin) {
-return _fseeki64(_File, _Offset, _Origin);
-  }
-  __mingw_static_ovr _off_t ftello(FILE *_File) {
-return ftell(_File);
-  }
-  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
-return _ftelli64(_File);
-  }
  #else
__MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int 
_Origin);
__MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
+#endif


I would suggest to get rid of #if here and simply always use _CRTIMP 
without __MINGW_EXTENSION. This would require adding symbols with 
__MINGW_IMP_SYMBOL to symbols in fseeki64.c.


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] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-25 Thread Liu Hao 
在 2018/11/24 上午5:37, Mateusz 写道:
> I've attached new patch -- mingw-w64-crt/Makefile.am is changed so you should 
> use automake before testing.
> 
> Now libmingwex.a is smaller (without _fseeki64 and _ftelli64 functions which 
> are moved to libmsvcrt.a). I can build and execute x265 linked to msvcrt.dll, 
> msvcr120.dll and ucrtbase.dll.
> 
> In old file mingw-w64-crt/stdio/fseeko64.c was function mingw_dosmaperr that 
> I don't know for what reason it was so I removed this function (there was 
> only one string 'mingw_dosmaperr' in whole mingw-w64 folder).

Martin, do you have any ideas on this patch?


-- 
Best regards,
LH_Mouse



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-23 Thread Mateusz 
W dniu 22.11.2018 o 09:51, Mateusz pisze:
> W dniu 21.11.2018 o 23:39, Martin Storsjö pisze:
>> On Wed, 21 Nov 2018, Mateusz wrote:
>>
>>> Problem is in libstdc++.a which uses fseeko64 from libmingwex.
>>>
>>> My proposition is:
>>> we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for 
>>> msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
>>> _ftelli64 from libmingwex10.
>>> For msvcrt spec file should be without changes
>>> ... -lmoldname -lmingwex -lmsvcrt
>>> for ucrtbase (and similar for msvcr120/110/100)
>>> ... -lmoldname -lmingwex10 -lucrtbase
>>
>> In general, so far, when using ucrt, we rely on a number of redirections in 
>> headers, so that an object file built for an older crt version won't 
>> necessarily work with the newer one. The exception to this, so far, has been 
>> the main CRT startup files and libmingw32/libmingwex. (We haven't checked 
>> all of libmingwex exhaustively, but only the parts that have been pulled in 
>> by code built in this setup.)
>>
>> In your case, the issue is that libstdc++.a contains a whole lot of object 
>> files built targeting another crt version.
>>
>> I would very much prefer not to have two separate versions of libmingwex. 
>> Instead it's often possible to tweak what libmingwex does, and tweak the 
>> headers and actual functions/stubs exported by libmsvcrt.a and libucrtbase.a 
>> so that the same single build of libmingwex.a works with both.
>>
>> If the __pioinfo function is the only issue with a libstdc++.a built against 
>> libmsvcrt.a but linked against libucrtbase.a, it might be worthwhile to try 
>> to work around it. To do that, the first step would be to look up what it is 
>> used for and what the replacing functionality is in ucrtbase. After that, 
>> one can e.g. change the headers to redirect the __piofunction to use the new 
>> ucrtbase mechansim in general, and add a wrapper in libmsvcr*.a that 
>> provides this interface. See e.g. src_msvcrt_common in 
>> mingw-w64-crt/Makefile.am for a few cases of doing this so far.
>>
>> A different strategy would be to move the helpers that differ depending on 
>> crt version from libmingwex.a into libmsvcr*.a and libucrtbase.a instead, to 
>> allow different versions/sets of them that actually match the CRT they are 
>> to be used with. In this case, move the parts that you wanted to 
>> differentiate in libmingwex into libmsvcr*.a and libucrtbase.a.
> 
> Thanks! I like the last approach -- we could remove _fseeki64 and _ftelli64 
> from libmingwex.a and move these functions to libmsvcrt.a and libmsvcr80.a 
> (there are already in libmsvcr90.a and newer).
> 
> I will make some tests and prepare new patch.

I've attached new patch -- mingw-w64-crt/Makefile.am is changed so you should 
use automake before testing.

Now libmingwex.a is smaller (without _fseeki64 and _ftelli64 functions which 
are moved to libmsvcrt.a). I can build and execute x265 linked to msvcrt.dll, 
msvcr120.dll and ucrtbase.dll.

In old file mingw-w64-crt/stdio/fseeko64.c was function mingw_dosmaperr that I 
don't know for what reason it was so I removed this function (there was only 
one string 'mingw_dosmaperr' in whole mingw-w64 folder).

Regards,
Mateusz
From 2c3234b7f75efce0c6fb0c872ebd79534948fbce Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Fri, 23 Nov 2018 19:16:43 +0100
Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to
 libmsvcrt

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am  |   1 +
 mingw-w64-crt/stdio/fseeki64.c | 171 +++
 mingw-w64-crt/stdio/fseeko64.c | 222 -
 mingw-w64-headers/crt/stdio.h  |  17 +---
 4 files changed, 175 insertions(+), 236 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/fseeki64.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a..f8b0623 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -210,6 +210,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/fseeki64.c \
   stdio/mingw_lock.c
 
 src_ucrtbase=\
diff --git a/mingw-w64-crt/stdio/fseeki64.c b/mingw-w64-crt/stdio/fseeki64.c
new file mode 100644
index 000..36d3274
--- /dev/null
+++ b/mingw-w64-crt/stdio/fseeki64.c
@@ -0,0 +1,171 @@
+/**
+ * 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 
+
+#define _IOYOURBUF  0x0100
+#define _IOSETVBUF  0x0400
+#define _IOFEOF 0x0800
+#define _IOFLRTN0x1000
+#define _IOCTRLZ0x2000
+#define _IOCOMMIT   0x4000
+
+/* General use macros */
+
+#define inuse(s)((s)->_flag & (_IOREAD|_IOWRT|_IORW))
+#define mbuf(s) ((s)->_flag & _IOMYBUF)
+#define nbuf(s)

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-22 Thread Mateusz 
W dniu 21.11.2018 o 23:39, Martin Storsjö pisze:
> On Wed, 21 Nov 2018, Mateusz wrote:
> 
>> Problem is in libstdc++.a which uses fseeko64 from libmingwex.
>>
>> My proposition is:
>> we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for 
>> msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
>> _ftelli64 from libmingwex10.
>> For msvcrt spec file should be without changes
>> ... -lmoldname -lmingwex -lmsvcrt
>> for ucrtbase (and similar for msvcr120/110/100)
>> ... -lmoldname -lmingwex10 -lucrtbase
> 
> In general, so far, when using ucrt, we rely on a number of redirections in 
> headers, so that an object file built for an older crt version won't 
> necessarily work with the newer one. The exception to this, so far, has been 
> the main CRT startup files and libmingw32/libmingwex. (We haven't checked all 
> of libmingwex exhaustively, but only the parts that have been pulled in by 
> code built in this setup.)
> 
> In your case, the issue is that libstdc++.a contains a whole lot of object 
> files built targeting another crt version.
> 
> I would very much prefer not to have two separate versions of libmingwex. 
> Instead it's often possible to tweak what libmingwex does, and tweak the 
> headers and actual functions/stubs exported by libmsvcrt.a and libucrtbase.a 
> so that the same single build of libmingwex.a works with both.
> 
> If the __pioinfo function is the only issue with a libstdc++.a built against 
> libmsvcrt.a but linked against libucrtbase.a, it might be worthwhile to try 
> to work around it. To do that, the first step would be to look up what it is 
> used for and what the replacing functionality is in ucrtbase. After that, one 
> can e.g. change the headers to redirect the __piofunction to use the new 
> ucrtbase mechansim in general, and add a wrapper in libmsvcr*.a that provides 
> this interface. See e.g. src_msvcrt_common in mingw-w64-crt/Makefile.am for a 
> few cases of doing this so far.
> 
> A different strategy would be to move the helpers that differ depending on 
> crt version from libmingwex.a into libmsvcr*.a and libucrtbase.a instead, to 
> allow different versions/sets of them that actually match the CRT they are to 
> be used with. In this case, move the parts that you wanted to differentiate 
> in libmingwex into libmsvcr*.a and libucrtbase.a.

Thanks! I like the last approach -- we could remove _fseeki64 and _ftelli64 
from libmingwex.a and move these functions to libmsvcrt.a and libmsvcr80.a 
(there are already in libmsvcr90.a and newer).

I will make some tests and prepare new patch.

Regards,
Mateusz



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

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-21 Thread Martin Storsjö 

On Wed, 21 Nov 2018, Mateusz wrote:


Problem is in libstdc++.a which uses fseeko64 from libmingwex.

My proposition is:
we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for 
msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
_ftelli64 from libmingwex10.
For msvcrt spec file should be without changes
... -lmoldname -lmingwex -lmsvcrt
for ucrtbase (and similar for msvcr120/110/100)
... -lmoldname -lmingwex10 -lucrtbase


In general, so far, when using ucrt, we rely on a number of redirections 
in headers, so that an object file built for an older crt version won't 
necessarily work with the newer one. The exception to this, so far, has 
been the main CRT startup files and libmingw32/libmingwex. (We haven't 
checked all of libmingwex exhaustively, but only the parts that have been 
pulled in by code built in this setup.)


In your case, the issue is that libstdc++.a contains a whole lot of object 
files built targeting another crt version.


I would very much prefer not to have two separate versions of libmingwex. 
Instead it's often possible to tweak what libmingwex does, and tweak the 
headers and actual functions/stubs exported by libmsvcrt.a and 
libucrtbase.a so that the same single build of libmingwex.a works with 
both.


If the __pioinfo function is the only issue with a libstdc++.a built 
against libmsvcrt.a but linked against libucrtbase.a, it might be 
worthwhile to try to work around it. To do that, the first step would be 
to look up what it is used for and what the replacing functionality is in 
ucrtbase. After that, one can e.g. change the headers to redirect the 
__piofunction to use the new ucrtbase mechansim in general, and add a 
wrapper in libmsvcr*.a that provides this interface. See e.g. 
src_msvcrt_common in mingw-w64-crt/Makefile.am for a few cases of doing 
this so far.


A different strategy would be to move the helpers that differ depending on 
crt version from libmingwex.a into libmsvcr*.a and libucrtbase.a instead, 
to allow different versions/sets of them that actually match the CRT they 
are to be used with. In this case, move the parts that you wanted to 
differentiate in libmingwex into libmsvcr*.a and libucrtbase.a.


// Martin


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

[Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

2018-11-21 Thread Mateusz 
Hello,

When I try to build x265 with ucrtbase (instead of msvcrt) I get errors:
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libucrt.a(dtwcs00041.o):(.text+0x0):
 multiple definition of `_fseeki64'; 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o):fseeko64.c:(.text+0x350):
 first defined here
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libucrt.a(dtwcs00045.o):(.text+0x0):
 multiple definition of `_ftelli64'; 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o):fseeko64.c:(.text+0x130):
 first defined here
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o):fseeko64.c:(.rdata$.refptr.__imp___pioinfo[.refptr.__imp___pioinfo]+0x0):
 undefined reference to `__imp___pioinfo'
collect2.exe: error: ld returned 1 exit status

Problem is in libstdc++.a which uses fseeko64 from libmingwex.

My proposition is:
we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for 
msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
_ftelli64 from libmingwex10.
For msvcrt spec file should be without changes
... -lmoldname -lmingwex -lmsvcrt
for ucrtbase (and similar for msvcr120/110/100)
... -lmoldname -lmingwex10 -lucrtbase

I've attached patch proposition that do what I described (you need to execute 
automake in mingw-w64-crt folder before build).

Now I can build and execute x265 (ucrt build).

I am not sure if it is the best way -- to make two libmingwex* and only one 
libstdc++.
So my question is -- we should go in this direction or not?

Regards,
Mateusz

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a4..f6ffd922 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -658,6 +658,10 @@ lib32_LIBRARIES += lib32/libmingwex.a
 lib32_libmingwex_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS)
 lib32_libmingwex_a_SOURCES = $(src_libmingwex) $(src_libmingwex32) 
$(src_dfp_math)
 
+lib32_LIBRARIES += lib32/libmingwex10.a
+lib32_libmingwex10_a_CPPFLAGS=$(CPPFLAGS32) -D__MINGW_LIBMINGWEX10 
$(extra_include) $(AM_CPPFLAGS)
+lib32_libmingwex10_a_SOURCES = $(src_libmingwex) $(src_libmingwex32) 
$(src_dfp_math)
+
 lib32_LIBRARIES += lib32/libmoldname.a
 lib32_libmoldname_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS)
 lib32_libmoldname_a_SOURCES = $(src_libm)
@@ -992,6 +996,10 @@ lib64_LIBRARIES += lib64/libmingwex.a
 lib64_libmingwex_a_CPPFLAGS=$(CPPFLAGS64) $(extra_include) $(AM_CPPFLAGS)
 lib64_libmingwex_a_SOURCES = $(src_libmingwex) $(src_libmingwex64) 
$(src_dfp_math)
 
+lib64_LIBRARIES += lib64/libmingwex10.a
+lib64_libmingwex10_a_CPPFLAGS=$(CPPFLAGS64) -D__MINGW_LIBMINGWEX10 
$(extra_include) $(AM_CPPFLAGS)
+lib64_libmingwex10_a_SOURCES = $(src_libmingwex) $(src_libmingwex64) 
$(src_dfp_math)
+
 lib64_LIBRARIES += lib64/libmoldname.a
 lib64_libmoldname_a_CPPFLAGS=$(CPPFLAGS64) $(extra_include) $(AM_CPPFLAGS)
 lib64_libmoldname_a_SOURCES = $(src_libm)
diff --git a/mingw-w64-crt/stdio/fseeko64.c b/mingw-w64-crt/stdio/fseeko64.c
index 5905aa22..a36c89ce 100644
--- a/mingw-w64-crt/stdio/fseeko64.c
+++ b/mingw-w64-crt/stdio/fseeko64.c
@@ -3,12 +3,18 @@
  * This file is part of the mingw-w64 runtime package.
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
+#ifdef __MINGW_LIBMINGWEX10
+#undef __MSVCRT_VERSION__
+#define __MSVCRT_VERSION__ 0x1000
+#endif
+
 #include 
 #include 
 #include 
 #include 
 #include 
 
+#if __MSVCRT_VERSION__ < 0x1000
 struct oserr_map {
   unsigned long oscode; /* OS values */
   int errnocode; /* System V codes */
@@ -103,6 +109,7 @@ int __cdecl _flush (FILE *str)
   stream->_cnt = 0ll;
   return rc;
 }
+#endif /* __MSVCRT_VERSION__ < 0x1000 */
 
 int fseeko64 (FILE* stream, _off64_t offset, int whence)
 {
@@ -130,6 +137,7 @@ int fseeko64 (FILE* stream, _off64_t offset, int whence)
   return fsetpos (stream, );
 }
 
+#if __MSVCRT_VERSION__ < 0x1000
 int __cdecl _fseeki64(FILE *str,__int64 offset,int whence)
 {
 FILE *stream;
@@ -256,3 +264,4 @@ void mingw_dosmaperr (unsigned long oserrno)
   else
 errno = EINVAL;
 }
+#endif /* __MSVCRT_VERSION__ < 0x1000 */
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index c79d7054..0a167a26 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
 
   /* Shouldn't be any fseeko32 in glibc, 32bit to