Statically linking against library built with different version of C Runtime Library, ok or bad?

≯℡__Kan透↙ 提交于 2019-12-04 02:58:01

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?

This is a very bad plan. Avoid. Either recompile the library in 2005 or compile the application in 2008.

Not a good idea at all. You have no control over the assumptions made by the runtime libraries and how they implement certain types. This is more likely going to create an unholy mess than not.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!