将MinGW可改变与由Visual C++编译的库链接起来有多安全。将gcc excutable链接到Visual C++库是否安全？
就像在这里解释的东西。 http://www.codesynthesis.com/~boris/blog/2011/12/09/oci-mingw/
TL; DR“......因为OCI是一个C库，我们可以采取‘官方’OCI进口的VC++库，oci.lib，其重命名为libclntsh.a，我们已经得到了OCI的MinGW的”
这是等待事故即将发生？有什么可能出错？
这取决于。 AFAIK，没有什么可以阻止glibc和msvcrt在Windows上的同一进程中共存 - 在Linux上发生的全局函数搜索不会发生在Windows上（每个动态导入都知道它来自哪个DLL - 函数不会合并到一个名称空间中）。
但是，特定库可能存在问题。如果库例如指定“该函数返回一个指针，该指针在完成时应该用free()释放”，则需要将其释放，其中正确的空闲，即与其分配的malloc()对应的空闲。同样，如果功能状态“参数是一个缓冲区，该功能将通过free()释放”，那么它必须与相应的malloc()一起分配。类似问题适用于可能使用realloc()的地方。
例如，当使用针对MSVCRT的不同版本编译的DLL时，也会发生此问题。 MSVCRT20.dll与MSVCRT40.dll。
这就是为什么Windows库总是说明应该如何分配内存。例如参见CoTaskMemAlloc/CoTaskMemFree，LocalAlloc/LocalFree，HeapAlloc/HeapFree。文档可能会声明“不再需要时，必须使用CoTaskMemFree释放buffere”。或者他们可以提供自己的免费/分配对，例如“不再需要时，必须使用SuperLibraryFreeBuffer释放返回的缓冲区”（内部可以简单地委托给CRT free，但至少它将是免费的正确版本）。
这是因为windows始终是一个多语言平台，可以用C语言以外的语言编写库。今天，我们可能会习惯Lisp，Pascal等是一个层C运行时，大多数程序员可能会认为即使在Pascal的情况下它不是真实的 - 但它并不总是这样：在C发明之前Pascal在DEC计算机上常用两年，众所周知，Windows遗产与DEC有许多共同之处。早期版本的Windows在汇编语言中写得很大，并且...在Windows 3头文件中存在“pascal”调用约定的原因您知道...
你提出重要的想法，但有人已经低估了你的答案我希望他们提供了原因。我在这方面没有足够的知识来判断你是正确的还是非现场的 – user841550 2012-04-27 17:03:37
请记住，即使所有模块都用VC编译，即使是相同的问题，从不同运行时库分配和释放内存的问题也可能发生版）。因此，将MinGW应用程序与VC库（特别是DLL）连接起来并不会真正增加这种混合效果。另外，请记住，就C运行时而言，MinGW不使用glibc（或者如果它只有一小部分）。 MinGW C运行时的大部分是作为Windows一部分提供的msvcrt.dll。我不确定C++运行时对兼容性有什么影响。 – 2012-04-28 05:54:15
名称修改不兼容性，实现之间的对齐差异，各种事物拼出潜在的厄运。 – 2012-04-27 15:31:45
C有一个ABI。通过C API连接是安全的。 C++不在Windows上。 – bmargulies 2012-04-27 15:54:49
我对ld连接器甚至处理微软的目标文件和库格式感到惊讶。因为这显然是一个使用C接口的DLL的导入库，所以事情可能会正常工作 - MinGW需要使用一般的DLL来在Windows上有用，所以它适用于DLL导入。我认为可能存在的主要问题是跨运行时库分配/释放内存的一般问题。但我怀疑OCI.dll是为了避免这种情况而设计的（因为这也是VC构建的问题）。 – 2012-04-28 05:47:13