将可执行的 gcc 与可执行的 gcc 与可视化C++库链接是否安全

Is it safe to link a gcc excutable with a Visual C++ library?

本文关键字：gcc 可执行是否安全链接可视化 C++ 更新时间：2023-10-16

将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 - 函数不会合并到单个命名空间中(。

但是，特定库可能存在问题。例如，如果库指定"函数返回一个指针，完成后应该用free()释放"，你需要使用正确的 free 释放它，即对应于分配它的malloc()的指针。同样，如果函数声明"参数是一个缓冲区，将由函数free()释放"，那么它必须与相应的malloc()一起分配。类似的问题适用于可能使用realloc()的地方。

例如，当使用针对不同版本的 MSVCRT 编译的 DLL 时，也会发生此问题，例如 MSVCRT20.dll 与 MSVCRT40.dll。

这就是为什么Windows库总是说明应该如何分配内存。例如参见CoTaskMemAlloc/CoTaskMemFree，LocalAlloc/LocalFree，HeapAlloc/HeapFree。文档可能会指出"当不再需要缓冲时，必须使用 CoTaskMemFree 释放缓冲区"。或者他们可以提供自己的 free/alloc 对，例如"当不再需要时，必须用 SuperLibraryFreeBuffer 释放返回的缓冲区"(内部可以简单地委托给 CRT free，但至少它将是正确的免费版本(。

这是因为 windows 一直是一个多语言平台，其中库可以用 C 以外的语言编写。今天，我们可能已经习惯了Lisp，Pascal等是C运行时之上的一层的想法 - 大多数程序员可能会认为即使它不像Pascal那样正确 - 但并不总是这样：在C被发明之前，Pascal在DEC计算机上普遍使用了两年，众所周知，Windows遗产与DEC有很多共同之处。Windows的早期版本是用汇编程序编写的，并且...你知道的 Windows 3 标头中的"Pascal"调用约定是有原因的......