Consider this scenario:
An application links to 3rd party library A.
A is built using MSVC 2008 and is statically linking (ie. built with /MT) to the C Runtime Library v9.0.
The application is built using MSVC 2005 and is statically linking to A and (using /MT) to the C Runtime Library v8.0.
I can see trouble with this – for instance if types are changed in the headers between runtime library versions.
Is care taken to keep the runtime library headers compatible between versions, or should one always make sure all statically linked libraries are linking to the same version of the runtime library?
It should not be a problem. Each library links to its own runtime and mostly functions independently from other libraries in the process. The problem comes about when the libraries ABI is badly defined. If any kind of heap allocated object is allocated in one library, passed across a library boundary and ‘freed’ in another library there are going to be problems as a different heap manager is being used to free a block from the heap manager used to allocate it.
Any kind of c-runtime defined struct, object or entity should not be passed accross boundries where a different runtime version might be being used :- FILE*’s obtained from one library for example will have no meaning to a different library linked against a different runtime.
As long as the library API’s use only raw types, and do not try to free() passed in pointers, or pass out pointers to internally malloc()’d memory that they expect the application (or another library) to free() you should be ok.
Its easy to fall for the FUD that “anything can go wrong” if c-runtimes are mixed, but you have to remember that libs, and dynamic libraries (.so / .dll / .dylib) have traditionally been developed in a wide variety of languages: allowing code written in asm, c, c++, fortran, pascal etc to comminicate via an effective CPU efficient binary interface.
Why suddenly panic when C is being linked to C?