C++ visual studio libraries

Question

Is there any way to make static libraries built in Microsoft Visual Studio independent from used CRT (with debug support / without it)?

I mean like, for simple C library it is possible to generate code using gcc and then use the same static library in visual studio. The resulting library.a file is completely independent from /MT or /MDd switches and does not result in warning / linking errors.

Comparing to Visual Studio default behaviour, you would have to build two versions of the same library - for Debug / Release modes independently. If you try to use the Release version in Debug configuration or vice-versa, this results in ugly warnings (warning LNK4098: defaultlib "LIBCMT" ...), but sometimes does not compile due to different runtimes?

Is there any way to avoid this? Or probably I'm doing something wrong?

Answer 1

Is there a problem with distributing 2 versions of the library? I don't claim to speak for everybody, but I always like to have a debug version, compiled against the static debug libs, with asserts and extra checking compiled in. (Symbols are good, too, of course!) The asserts and checks are helpful, the stack traces are usually better when the thing crashes in the library code, and it's often easier to read the disassembly.

Answer 2

To make a lib that will link in regardless of runtime selection it is necessary to use two switches:

/MT to build against the basic release runtime, /Zl to omit the default library names.

Building against the dll runtimes will cause the compiler to decorate all the runtime symbols with __imp_ (so, for example, it will try and link against __imp__fread rather than _fread). So you have to choose one of the static runtimes.

The compiler does an implicit default library pragma, depending on the lib selected:

#pragma comment(lib,"libcmtd.lib")

is how it looks in code. The /Zl causes the compiler to omit all these directives - (implicit and explicit) from the resulting .obj (and hence .lib) file. So the result will should link cleanly without causing default library conflicts.

Answer 3

No. The object files for the default release and debug configurations are completely different -- debug object binaries are relocatable machine executable object code, release object binaries are simply an intermediate representation of the original code. That is, the backend is in the linker for release builds, but is in the compiler for debug builds. Putting the backend is in the Linker allows the compiler back end to make more intelligent decisions with respect to optimization of your program, at the expense of longer compilation times.