3

I am using:

  • VS 2017
  • MinGW with GCC/G++ 7.4.0.

Basically what is happening goes as follows:

  1. An executable is built using VS 2017
  2. An .so is built with GCC
  3. The .so is loaded by the executable created in step 1

The issue stems from the MSVCRT. MinGW by default links against MSVCRT.DLL and the executable created using VS 2017 uses VCRUNTIME140.DLL and UCRTBASE.DLL.

When the .so is loaded two CRT exist the one from MSVCRT.DLL and the other from VCRUNTIME140.DLL and UCRTBASE.DLL. This causes random issues/memory issues during application runtime.

The solution for that is to have MinGW link against VCRUNTIME140.DLL instead of MSVCRT.DLL. I have done that by creating an import library from VCRUNTIME140.DLL added it to MinGW and dumped the GCC specs and modified it to have it link to the VCRUNTIME140.DLL and UCRTBASE.DLL.

My problem now is the scanf family functions. I can't seem to find the scanf functions within VCRUNTIME140.DLL or UCRTBASE.DLL.

Where does the scanf family lie now in the whole new UCRT thing?

So, I just compiled a small test application which makes use of scanf and compiled it using VS 2017 and found that it uses API-MS-WIN-CRT-STDIO-L1-1-0.DLL which then uses UCRTBASE.DLL for scanf which appears this way __stdio_common_vscanf.

I am now so confused. Is there any kind of a clean way to reference scanf functions by MinGW GCC?

Ayman Salah
  • 1,039
  • 14
  • 35

1 Answers1

0

I was able to get rid of the undefined scanf errors during linking by only adding -D_UCRT to cpp and cc1plus parts of the GCC spec file.

I reached this solution after checking the sources found in stdio folder of mingw src\mingw-w64\mingw-w64-crt\stdio and some threads in the discussion forum of MinGW sourceforge.

MinGW stdio.h had #ifdef _UCRT around scanf related functions.

Ayman Salah
  • 1,039
  • 14
  • 35