date:20181127

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

2018-11-27 Thread Liu Hao

在 2018/11/28 0:57, Jacek Caban 写道:
> Signed-off-by: Jacek Caban 
> ---
>  mingw-w64-crt/Makefile.am | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> 

What is the rationale for this? I can see
`_set_invalid_parameter_handler` exported from both x86 and x64 MSVCR80.DLL.


-- 
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] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

2018-11-27 Thread Jacek Caban


Hi Mateusz,


On 27/11/2018 22:32, Mateusz wrote:

W dniu 27.11.2018 o 20:28, Mateusz pisze:

W dniu 27.11.2018 o 17:57, Jacek Caban pisze:

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

Thanks! I've added stdio/fseeki64.c and stdio/mingw_lock.c and was able to 
build x265.

Bad news is that x265 is not working -- it displays message box:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: f:\speed\2.9+9\x265m08.exe
R6034
An application has made an attempt to load the C runtime
library incorrectly.
Please contact the application's support team for more
information.
[OK]

It is much better but not perfect.

I have the same problem with exe linked to msvcr90.dll (on Windows 10 64-bit 
Home). I can run exe linked to msvcr100/110/120.dll, ucrtbase.dll and 
msvcrt.dll.

Is it needed something special to run exe linked to msvcr80/90.dll on 64-bit 
Win10?


Those DLLs required manifests to be loaded properly from winsxs. It 
failed if it detected that it was loaded without manifest. They dropped 
that horrible idea with msvcr100.


(FWIW, that's one of reasons why I consider msvcr80 and msvcr90 to be 
barely useful for mingw-w64 and good candidates for dropping).


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] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

2018-11-27 Thread Martin Storsjö


On Tue, 27 Nov 2018, Mateusz wrote:


W dniu 27.11.2018 o 20:28, Mateusz pisze:

W dniu 27.11.2018 o 17:57, Jacek Caban pisze:

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


Thanks! I've added stdio/fseeki64.c and stdio/mingw_lock.c and was able to 
build x265.

Bad news is that x265 is not working -- it displays message box:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: f:\speed\2.9+9\x265m08.exe
R6034
An application has made an attempt to load the C runtime
library incorrectly.
Please contact the application's support team for more
information.
[OK]

It is much better but not perfect.


I have the same problem with exe linked to msvcr90.dll (on Windows 10 64-bit 
Home). I can run exe linked to msvcr100/110/120.dll, ucrtbase.dll and 
msvcrt.dll.

Is it needed something special to run exe linked to msvcr80/90.dll on 64-bit 
Win10?


IIRC those versions required some extra setup for loading the msvcrt dll, 
some manifest or similar (it shouldn't be specific to Win10).


// 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] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

2018-11-27 Thread Mateusz

W dniu 27.11.2018 o 20:28, Mateusz pisze:
> W dniu 27.11.2018 o 17:57, Jacek Caban pisze:
>> Signed-off-by: Jacek Caban 
>> ---
>>  mingw-w64-crt/Makefile.am | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> Thanks! I've added stdio/fseeki64.c and stdio/mingw_lock.c and was able to 
> build x265.
> 
> Bad news is that x265 is not working -- it displays message box:
> Microsoft Visual C++ Runtime Library
> Runtime Error!
> Program: f:\speed\2.9+9\x265m08.exe
> R6034
> An application has made an attempt to load the C runtime
> library incorrectly.
> Please contact the application's support team for more
> information.
> [OK]
> 
> It is much better but not perfect.

I have the same problem with exe linked to msvcr90.dll (on Windows 10 64-bit 
Home). I can run exe linked to msvcr100/110/120.dll, ucrtbase.dll and 
msvcrt.dll.

Is it needed something special to run exe linked to msvcr80/90.dll on 64-bit 
Win10?

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] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

2018-11-27 Thread Mateusz

W dniu 27.11.2018 o 17:57, Jacek Caban pisze:
> Signed-off-by: Jacek Caban 
> ---
>  mingw-w64-crt/Makefile.am | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

Thanks! I've added stdio/fseeki64.c and stdio/mingw_lock.c and was able to 
build x265.

Bad news is that x265 is not working -- it displays message box:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: f:\speed\2.9+9\x265m08.exe
R6034
An application has made an attempt to load the C runtime
library incorrectly.
Please contact the application's support team for more
information.
[OK]

It is much better but not perfect.

Regards,
Mateusz



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

[Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

2018-11-27 Thread Jacek Caban


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


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index f8b0623c..9ab59f66 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -253,8 +253,12 @@ src_msvcrtarm64=\
   misc/__p__fmode.c \
   misc/__p__wcmdln.c
 
-src_msvcr80_64=\
+src_msvcr80=\
   $(src_msvcrt_common) \
+  misc/invalid_parameter_handler.c
+
+src_msvcr80_64=\
+  $(src_msvcr80) \
   misc/__p___argv.c \
   misc/__p__acmdln.c \
   misc/__p__fmode.c \
@@ -685,7 +689,7 @@ lib32_libcrtdll_a_AR = $(DTDEF32) $(top_srcdir)/lib32/crtdll.def && $(AR) $(ARFL
 lib32_libcrtdll_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libmsvcr80.a
-lib32_libmsvcr80_a_SOURCES = $(src_msvcrt_common) lib32/msvcr80.def.in
+lib32_libmsvcr80_a_SOURCES = $(src_msvcr80) lib32/msvcr80.def.in
 lib32_libmsvcr80_a_AR = $(DTDEF32) lib32/msvcr80.def && $(AR) $(ARFLAGS)
 lib32_libmsvcr80_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes)
 EXTRA_lib32_libmsvcr80_a_DEPENDENCIES=lib32/msvcr80.def

___
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 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] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

[Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

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

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

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

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

10 matches

Site Navigation

Mail list logo

Footer information