Menu
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?
983
The major disadvantages of static linking are increases in the memory required to run an executable, network bandwidth to transfer it, and disk space to store it.
In computer science, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable.
Static libraries are just collections of object files that are linked into the program during the linking phase of compilation and are not relevant during runtime.
The C runtime Library (CRT) is the part of the C++ Standard Library that incorporates the ISO C standard library. The Visual C++ libraries that implement the CRT support native code development, and both mixed native and managed code. All versions of the CRT support multi-threaded development.
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?
135
This is a very bad plan. Avoid. Either recompile the library in 2005 or compile the application in 2008.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
