将 MinGW 可执行文件与由 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”
这是一场等待发生的事故吗？会出什么问题？
最佳答案
视情况而定。
AFAIK，没有什么可以阻止 glibc 和 msvcrt 在 Windows 上的同一进程中共存 - 在 Linux 上发生的相同全局函数搜索不会在 Windows 上发生(每个动态导入都知道它来自哪个 DLL -函数未合并到单个 namespace 中)。
但是，特定库可能存在问题。例如，如果库指定“函数返回一个指针，完成后应使用 free() 释放它”，您需要使用正确的 free 释放它，即与分配给它的 malloc() 相对应的那个。同样，如果函数声明“参数是一个缓冲区，它将由函数使用 free() 释放”，那么它必须使用相应的 malloc() 进行分配。类似的问题适用于可能使用 realloc() 的地方。
例如，当使用针对不同版本的 MSVCRT 编译的 DLL 时，也会出现此问题，例如MSVCRT20.dll 与 MSVCRT40.dll。
这就是为什么 Windows 库总是声明应该如何分配内存。参见例如 CoTaskMemAlloc/CoTaskMemFree、LocalAlloc/LocalFree、HeapAlloc/HeapFree。文档可能会声明“当不再需要时，必须使用 CoTaskMemFree 释放缓冲区”。或者他们可以提供自己的 free/alloc 对，例如“当不再需要时，必须使用 SuperLibraryFreeBuffer 释放返回的缓冲区”(在内部可能只是委托(delegate)给 CRT free，但至少它将是 free 的正确版本)。
这是因为 Windows 一直是一个多语言平台，在这里可以用 C 以外的语言编写库。今天我们可能习惯于认为 Lisp、Pascal 等是 C 之上的一层运行时，-大多数程序员可能会假设，即使它不像 Pascal 那样真实 - 但它并不总是这样:在 C 发明之前，Pascal 在 DEC 计算机上普遍使用了两年，而 Windows众所周知，传统与 DEC 有很多共同之处。 Windows 的早期版本主要是用汇编程序编写的，并且...您知道，在 Windows 3 header 中使用“pascal”调用约定是有原因的...
关于c++ - 将 gcc 可执行文件与 Visual C++ 库链接是否安全？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10353387/