2

When I need to build some third party library to be used in several of my projects under different version of MSVC, I usually build it for every MSVC version and for both Debug and Release configurations. That's what boost does, and that's what we have been done for our whole life in my team.

However, I still don't get, why couldn't I just build this library with like... whatever. All I need is function prototype and object code, right? Since I'm linking CRT statically, I have no external dependencies. But when I'm trying to link library built in Release under MSVC8 with my project in Debug under MSVC10 I have this annoying "already defined" linker errors which we all hate so much.

But why? Can I just "encapsulate" all this functions inside lib and do not export them so that my project will take only what it needs from the lib? Why can I have precompiled version of libpng and zlib which I can link in every project? Yes, they are not build using MSVC, I guess, but the still uses the same functions of CRT. So can anyone please explain in depth or share a link to some enlightened explanation of this issue?

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
Mikhail
  • 20,685
  • 7
  • 70
  • 146

1 Answers1

3

Since I'm linking CRT statically, I have no external dependencies

Well, that's not true, you do have a dependency. On the static version of the CRT. Debug or Release, depending on your build settings. And it is an external dependency, the linker glues the CRT later, when the library gets linked. The code that uses the library also has a dependency on the CRT. And if the compile settings don't match then the linker barfs.

You isolate that dependency by building a DLL instead of a static link library. You must further ensure that the exported functions don't cause a CRT dependency. You can't return a C++ object from the standard C++ library and can't return a pointer to an object that needs to be released by the client code. Even passing structures is tricky since their packing is an implementation detail, but you usually get away with it. A good practical example is COM automation, it forces you into using a subset of types that are universal. Windows is rife with them and all these servers work with any version of the compiler or CRT. Even any language. This however comes at a cost, writing such a library isn't as simple or convenient as just throwing a bunch of code in a static lib.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Nice answer! "...linker glues the CRT later, when the library gets linked..." - and is there a way to force linker to link CRT functions in .lib? I can have my own code linked in, why cannot I force CRT to be linked? – Mikhail Mar 15 '12 at 16:38
  • 1
    That's not how static .libs work. It is a very simple file format, just a collection of .obj files. You force the linker to link the CRT by creating a DLL. – Hans Passant Mar 15 '12 at 16:55