15

I am trying to use a library compiled with mingw in visual studio. However, I get the following linker errors:

error LNK2001: unresolved external symbol __imp___iob

error LNK2019: unresolved external symbol __imp___pctype referenced in function

error LNK2019: unresolved external symbol __imp____mb_cur_max referenced in function

error LNK2001: unresolved external symbol _fprintf

I was able to fix the _fprintf error by linking against legacy_stdio_definitions.lib as per this post : unresolved external symbol __imp__fprintf and __imp____iob_func, SDL2.

However, I have no idea how to fix the other three unresolved externals. How can I fix this? The libraries work perfectly under Visual Studio 2013.

Edit:

Okay here is an update. I moved libmsvcrt.a from the mingw lib folder into Visual Studio, and I added that to the linker settings. Now it seems to work correctly.

Community
  • 1
  • 1
stack_tom
  • 950
  • 2
  • 9
  • 18
  • The MinGW team has a bunch of work to do to make their .h files compatible with the VS2015 version of the CRT. Don't hold your breath for that, you'll probably be stuck with the VS2013 version for a while. – Hans Passant Jul 21 '15 at 18:35
  • Before I mark the below answer, is there any quick hack to getting this to work? According to this : http://stackoverflow.com/questions/30412951/unresolved-external-symbol-imp-fprintf-and-imp-iob-func-sdl2, one can solve the __imp___iob error by defining __imp___iob to return some sort of array. How would one go about fixing the other two linker errors and how would this array be defined? – stack_tom Jul 21 '15 at 18:38
  • 2
    You'll just break C runtime functions in a very hard to diagnose way. Don't go there. – Hans Passant Jul 21 '15 at 18:40
  • I too found this kind of problem when carelessly tried to compile a x86 project with a x64 library. – ChrCury78 Jan 09 '21 at 13:29

2 Answers2

7

The libraries were compiled against an old version of the CRT. The unresolved symbols you get are internal symbols of the CRT that are present in the compiled library. You have to recompile the library against the VS2015 CRT (the Universal CRT). But I'm not sure if MinGW supports this.

If you can't do that, you have to continue to use the VS2013 compiler. (You can use the VS2015 IDE, by setting the toolset to vs2013 in the project options. But you'll still be limited to the C++ features the 2013 compiler supports.)

Sebastian Redl
  • 69,373
  • 8
  • 123
  • 157
  • Guess I'll have to wait until mingw is updated. I wish there was a way to build these lib's using Visual Studio's makefile project ability, but I can't get the ./configure to work. – stack_tom Jul 21 '15 at 19:06
  • Okay here is an update. I moved libmsvcrt.a from the mingw lib folder into Visual Studio, and added that to the linker settings. Now it seems to work correctly. Is there any disadvantage to doing this? One has to add mingw's libgcc.a to VS to be able to use lib's compiled with mingw anyway, so I don't believe so – stack_tom Jul 21 '15 at 22:07
  • Yes. The downside is that the library and your program are using different CRTs. Some of the more interesting effects that can occur: if the library calls malloc, a call to free on that pointer by your program might crash, or vice versa; the library and your program have separate global locales. – Sebastian Redl Jul 22 '15 at 07:30
2

I encountered the same problem (library compiled with static CRT instead of CRT in DLL) and I managed to make it work by changing the two following parameters in Project Properties:

  • Linker > Input > Ignore specific default libraries: libc.lib
  • C/C++ > Code Generation > Runtime Library: Multi-threaded Debug (/MTd)

If that's not enough, there's more at following page: https://social.msdn.microsoft.com/Forums/en-US/841e5723-bce4-4340-b7b3-027dcdf90f00/

FlorianT
  • 1,147
  • 11
  • 16