Question

I want to write a (static) library for other programmers to use that uses the compiler’s optimisations.

Whilst writing and testing the library using debug builds I find it runs quite slowly, but if I switch to a release build then it seems to be acceptably fast.

At the moment I’ve compiled the library as a debug build and I’m using it in another project and I notice how slowly it runs, but if I try to switch my new project to a release build, then the link fails with lots of errors like this:

LIBCMTD.lib(tzset.obj) : error LNK2005: __tzset already defined in MSVCRT.lib(MSVCR90.dll)

What settings should I use when building my library so that programmers can use the library in their own projects so it runs acceptably quickly whether they use debug or release builds?

Answer 1

This is the old problem of static libraries: it has to use the same CRT of the executable that links against it, otherwise the linker will find conflicting versions of the same CRT routines and data structures (both the public and the internal ones).

Since there are currently 4 versions of the CRT (all the debug/release and dll/static link combinations), you should provide 4 different .lib files of your library. Incidentally, this is one of the reasons why almost nobody distributes static libraries in .lib form (unless they are just import libraries), but provide the sources to be compiled in any way the library user prefers.

If you don’t like this, you should consider distributing your library as a dll. In this last case, you still must be careful about the CRT, because if the dll and the program that uses it do not share the same CRT (e.g. one of them uses the static-linking version of the CRT, or they use different versions of the dynamic-linking CRT) you cannot rely on several C++ facilities to work correctly; the most evident problem is that you cannot delete stuff that was allocated with new by the other module, because the two CRTs are using two separated heaps.

Also, trying to pass types defined in the C++ library across the modules will probably result in problems, because nothing guarantees that they are binary compatible across different CRT versions (and often they won’t). RTTI and exceptions are also problematic areas if you mismatch CRTs.

Long story short: with static libraries, you must match the CRTs, otherwise the various modules won’t link together. With dlls, match correctly the CRTs and everything should work fine. Otherwise, the only wise alternative is to provide a C-style interface and let each module manage its memory allocations (perhaps exporting its malloc/free to let other modules allocate/free the memory from the module’s heap).