I've figured out what's going on. The problem here has nothing to do with Windows 8 vs. 7.
_set_invalid_parameter_handler was introduced in Visual C++ 2005, and only appears in MSVCR80.DLL and later. (So it is in MSVCR90.DLL, MSVCR90D.DLL, MSVCR100.DLL, etc.) Therefore the symbol should only appear in libmsvcr90.a and above.
Unfortunately it was added -- by mistake -- to earlier MinGW import libraries in /lib. It is in libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a. The first of these is especially a problem because it is the default library for MinGW GCC. It needs to be removed from those libraries, because the corresponding DLLs do not export it.
This error is causing all current MinGW builds of Bison (Yacc), a standard Unix tool, to crash at startup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem here has nothing to do with Windows 8 vs. 7.
We care about the Windows version supplying msvcrt.dll and whether or not a symbol is supplied by MSVCRT.DLL. The other DLL are not guaranteed to exist on Windows OS and present us with a differing issue of memory clobbering that requires one to muck with the GCC specs to get correct. Just wanted to make clear that problems have everything to do with a Windows OS version.
Unfortunately it was added -- by mistake -- to earlier MinGW import libraries in /lib. It is in libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a. The first of these is especially a problem because it is the default library for MinGW GCC. It needs to be removed from those libraries, because the corresponding DLLs do not export it.
In version 5.0 I plan to break this apart and supply different .def files instead of the one .def.in file. It will be easier for us to get the symbols correct per the versioned libraries. At some point GCC needs to be able to handle a user request to use these libraries gracefully within a common GCC spec file.
This error is causing all current MinGW builds of Bison (Yacc), a standard Unix tool, to crash at startup.
I'll use these to test my changes which for 4.1 may be a complete removal of the symbol from the header and library file but I'll try to avoid removing it from libmsvcr80 and above.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The symbol should continue to appear in libmsvcr80.a, libmsvcr80d.a, libmsvcr90.a, libmsvcr90d.a, libmsvcr100.a, libmsvcr100d.a.
It should be removed from libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a, libmsvcr71.a, libmsvcr71d.a.
(This is true for both the _set_invalid_parameter_handler symbol and its import stub, but I assume that will automatically be handled by the tools that build the libmsvcr*.a import libraries.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've created a __MINGW_MSVCR_PREREQ(runtime) macro function to test that __MSVC_RUNTIME__ is defined and greater than or equal to (runtime). I then changed stdlib.h to use that macro to declare the _set_invalid_parameter_handler function. The plan will be to let GCC define __MSVC_RUNTIME__ version based on a -msvc=## or similar switch controlled via the specs which will also control the linker library specification. Until then the user will -D__MSVC_RUNTIME__=## in the CFLAGS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
maybe dumb question, but which version do I have to use to get that thing fixed? Is it yet released or what does "fixed, needs test" imply? Is there a nightly build, maybe?
Last edit: JensG 2014-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
He says he fixed it, but I'm not convinced. All his faffing aside, the fundamental problem is that he gratuitously -- and extremely foolishly -- removed all of the version specific filters from the msvcrt.def.in file, (which is what defines the content for all variants of libmsvcr*.a); the correct solution is to reinstate those filters, and he most definitely has not done so; until he does, this cannot be classified as fixed.
This problem was not apparent in mingwrt-3.20, (where exposure of the offending symbol is correctly restricted to msvcr80.dll and greater numbered variants); I suggest you continue to use that.
Last edit: Keith Marshall 2014-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've figured out what's going on. The problem here has nothing to do with Windows 8 vs. 7.
_set_invalid_parameter_handler was introduced in Visual C++ 2005, and only appears in MSVCR80.DLL and later. (So it is in MSVCR90.DLL, MSVCR90D.DLL, MSVCR100.DLL, etc.) Therefore the symbol should only appear in libmsvcr90.a and above.
Unfortunately it was added -- by mistake -- to earlier MinGW import libraries in /lib. It is in libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a. The first of these is especially a problem because it is the default library for MinGW GCC. It needs to be removed from those libraries, because the corresponding DLLs do not export it.
This error is causing all current MinGW builds of Bison (Yacc), a standard Unix tool, to crash at startup.
We care about the Windows version supplying msvcrt.dll and whether or not a symbol is supplied by MSVCRT.DLL. The other DLL are not guaranteed to exist on Windows OS and present us with a differing issue of memory clobbering that requires one to muck with the GCC specs to get correct. Just wanted to make clear that problems have everything to do with a Windows OS version.
In version 5.0 I plan to break this apart and supply different .def files instead of the one .def.in file. It will be easier for us to get the symbols correct per the versioned libraries. At some point GCC needs to be able to handle a user request to use these libraries gracefully within a common GCC spec file.
I'll use these to test my changes which for 4.1 may be a complete removal of the symbol from the header and library file but I'll try to avoid removing it from libmsvcr80 and above.
Specifically:
The symbol should continue to appear in libmsvcr80.a, libmsvcr80d.a, libmsvcr90.a, libmsvcr90d.a, libmsvcr100.a, libmsvcr100d.a.
It should be removed from libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a, libmsvcr71.a, libmsvcr71d.a.
(This is true for both the _set_invalid_parameter_handler symbol and its import stub, but I assume that will automatically be handled by the tools that build the libmsvcr*.a import libraries.)
I've created a
__MINGW_MSVCR_PREREQ(runtime)macro function to test that__MSVC_RUNTIME__is defined and greater than or equal to(runtime). I then changed stdlib.h to use that macro to declare the _set_invalid_parameter_handler function. The plan will be to let GCC define__MSVC_RUNTIME__version based on a-msvc=##or similar switch controlled via the specs which will also control the linker library specification. Until then the user will-D__MSVC_RUNTIME__=##in the CFLAGS.Hi,
maybe dumb question, but which version do I have to use to get that thing fixed? Is it yet released or what does "fixed, needs test" imply? Is there a nightly build, maybe?
Last edit: JensG 2014-07-19
He says he fixed it, but I'm not convinced. All his faffing aside, the fundamental problem is that he gratuitously -- and extremely foolishly -- removed all of the version specific filters from the msvcrt.def.in file, (which is what defines the content for all variants of libmsvcr*.a); the correct solution is to reinstate those filters, and he most definitely has not done so; until he does, this cannot be classified as fixed.
This problem was not apparent in mingwrt-3.20, (where exposure of the offending symbol is correctly restricted to msvcr80.dll and greater numbered variants); I suggest you continue to use that.
Last edit: Keith Marshall 2014-07-19