1

I made a static library, but there are some ploblems.

  1. I compiled my library in VS2015. Then, it cannot be used in VS2013. '_MSC_VER mismatch' and 'error LNK2001: __imp____stdio_common_vfprintf'

I don't think I should compile my library with both version of VS and release them. I never have considered the version of compiler when I used libraries. Besides, I don't have VS2013.

How can I fix this error?

  1. I have thought I have to make two libraries : debug version and release version. However, it seems that Opengl doesn't do it. I use opengl32.lib regardless of debug/release mode. I never seen opengl32d.lib. How to do this?
Gimun Eom
  • 411
  • 5
  • 17
  • These are the kind of linker errors you get when you compile code in one VS version and try to link it in another version. Most basic mishap is that the #include files that were used when the code was compiled do not match the C runtime library version that is linked. That's very bad, such code is unlikely to run correctly. So the linker puts an early stop to it. You say "my library" but that doesn't match these linker errors, you are probably using some other library as well. it needs to be recompiled. – Hans Passant Nov 26 '16 at 09:25
  • @HansPassant My library just uses standard libraries, and the error is because of standard library. I recognized that it is the same error with http://stackoverflow.com/questions/30412951/unresolved-external-symbol-imp-fprintf-and-imp-iob-func-sdl2', but I cannot sure the solution. I don't think that I have to make two library: for VS2013, VS2015. It is ridiculous. – Gimun Eom Nov 26 '16 at 09:51
  • @HansPassant Then Should I make definitions for another version with #ifdef macro and _MSC_VER? It is also doubful. It means that I have to do same thing for another compiler that has same errors. (or I should say "Sorry, we don't support that compiler.) So I thinke that it cannot be the fundamental solution. – Gimun Eom Nov 26 '16 at 09:53
  • Oh, wait, this isn't an accident, you did it on purpose. Best to convey "it is ridiculous" messages to Microsoft, little point in complaining about it to people that can't do anything about it. VS2015 has **drastic** changes, it introduced the universal runtime library The front-end was also completely rewritten, now supporting C99, a requirement to get full C++1x compatibility. Versioning is always a deep concern in C++, and entirely a programmer's concern, if you don't want to deal with it then a VM language like Java or C# is the better choice. – Hans Passant Nov 26 '16 at 10:00
  • @HansPassant Then if I compile the library in VS2013 and use the libary in VS2015, the errors don't occur? – Gimun Eom Nov 26 '16 at 10:33
  • They will, exact same problem of course. If you want to supply a static library then you must build one for every VS version you want to support **and** you must supply both a Debug and a Release built version. Otherwise the reason libraries are often supplied as DLLs instead and why an interface-based programming technique like COM or pimpl is often used. – Hans Passant Nov 26 '16 at 10:39
  • @HansPassant In case of glew32s.lib, it support all version and both debug and release mode. I know that it doesn't use dll file. How can it be done? – Gimun Eom Nov 26 '16 at 10:50
  • Not having a CRT dependency is the minimum requirement. Somewhat feasible for GLEW since it is just a simple wrapper for OpenGL. And is very old with a Unix background, there have been many incompatible Unix versions, forcing the authors to deal with portability concerns early. And it is a C library, always a lot easier to make portable than C++. Still no panacea, this site has over 3000 posts about GLEW getting programmers in trouble. Ensuring a library is compatible with *everything* is a lot of work and easily fumbled. – Hans Passant Nov 26 '16 at 11:08

0 Answers0