将 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"
这是一场等待发生的事故吗？会出什么问题？
问问题
925 次
1 回答
2
这取决于。
AFAIK，没有什么可以阻止 glibc 和 msvcrt 在 Windows 上的同一进程中共存 - 在 Linux 上发生的相同全局函数搜索不会在 Windows 上发生（每个动态导入都知道它来自哪个 DLL - 函数不是合并到一个命名空间中）。
但是，特定库可能存在问题。例如，如果库指定“函数返回一个指针，完成后应该释放它free()”，您需要使用正确的释放它来释放它，即与malloc()分配它的那个相对应。同样，如果函数声明“参数是一个将被free()函数释放的缓冲区”，那么它必须分配相应的malloc(). 类似的问题适用于realloc()可能使用的地方。
例如，当使用针对不同版本的 MSVCRT（例如 MSVCRT20.dll 与 MSVCRT40.dll）编译的 DLL 时，也会出现此问题。
这就是为什么 windows 库总是说明应该如何分配内存的原因。参见例如 CoTaskMemAlloc/CoTaskMemFree、LocalAlloc/LocalFree、HeapAlloc/HeapFree。文档可能会声明“当不再需要缓冲区时，必须使用 CoTaskMemFree 释放”。或者他们可以提供他们自己的 free/alloc 对，例如“当不再需要返回的缓冲区时，必须使用 SuperLibraryFreeBuffer 释放”（内部可以简单地委托给 CRT free，但至少它将是正确的 free 版本）。
这是因为 windows 一直是一个多语言平台，其中库可以用 C 以外的语言编写。今天我们可能已经习惯了 Lisp、Pascal 等是 C 运行时之上的一层的想法，-大多数程序员可能会认为，即使它不像 Pascal 那样是正确的——但情况并非总是如此：在 C 发明之前，Pascal 在 DEC 计算机上已普遍使用了两年，而 Windows 的遗产就像每个人一样知道与 DEC 有很多共同点。Windows 的早期版本在很大程度上是用汇编程序编写的，并且......您知道的 Windows 3 标头中的“pascal”调用约定是有原因的......
于 2012-04-27T16:18:44.457 回答