On 2017/10/19 18:22, Mateusz Mikuła wrote:
You can try linking to different version of runtime library [0] like MSVC
does by default.
[0]
https://stackoverflow.com/questions/3402252/how-to-link-against-msvcr90-dll-with-mingw-gcc
MSVCR90 have been in the DLL hell for a decade so linking against it is
not recommended. You can search for `MSVCR90.DLL` in your Windows
directory and see how many incompatible copies of it exist. Linking
against MSVCR90 will fail at run time without a proper .manifest file.
Also the answer on Stack Overflow is ineffective: After you build your
program with `-lmsvcr100`, you will find the following hello-world
program import `malloc()` from MSVCR100.DLL and `free()` from
MSVCRT.DLL. This means some code in the executable allocates memory
using the former, but deallocates it using the latter, which will result
in memory corruption. At the moment, it is our `atexit()` function that
is causing this problem, because being in one of the CRT startup files
it follows any user-provided libraries (-lmsvcr100) but precedes
hard-coded ones in the built-in specs of GCC (-lmsvcrt) in the final
linker command line, and the order is significant.
If you are using an MSYS2 GCC, the CRT DLL can be overriden using the
`-mcrtdll=msvcr100` option, otherwise you would have to dump, edit then
re-import GCC's specs. These are the only ways to link against newer CRT
DLLs safely.
```c
/* Try `gcc test.c -lmsvcr100` then take a look at
the import table of the executable generated. */
#include <stdlib.h>
#include <stdio.h>
void bark(void){
puts("hello world!");
}
int main(void){
atexit(bark);
}
```
--
Best regards,
LH_Mouse
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
