将MinGW excutable与由Visual C ++编译的库链接的安全性如何。
像这里解释的那样。 http://www.codesynthesis.com/~boris/blog/2011/12/09/oci-mingw/
TL; DR“...因为OCI是一个C库，我们可以为VC ++采用”官方“OCI导入库，oci.lib，将其重命名为libclntsh.a，我们为MinGW提供了OCI”< / p>
这是一场等待发生的事故吗？可能出现什么问题？
答案 0 :(得分：2)
取决于。
AFAIK，没有什么可以阻止glibc和msvcrt在Windows上的同一进程中共存 - 在Linux上不会发生在Linux上发生的相同的全局函数搜索（每个动态导入都知道它来自哪个DLL - 函数不会合并在一个名称空间中。）
但是特定库可能存在问题。如果库指定例如“函数返回一个指针，完成时应该用free()释放”，你需要释放正确 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”调用约定...