我的主机应用程序接管了例如来自动态库的 FILE 对象。即使我的主机应用程序和动态库是使用不同版本的 clang/gcc 编译的，我能否在此对象上安全地调用 fclose()？
背景
在 Windows 上(具有不同的 VS 运行时)这是非法的，我必须首先从动态库使用的运行时库中提取 fclose() 函数，因为所有运行时都有自己的文件或内存对象的池和内部结构。
Windows 中情况的图示如下所示:
此限制是否也适用于 Linux 和 macOS？
最佳答案
问题不在于您的应用程序和动态库是否是使用不同版本的 clang 和/或 gcc 编译的。问题是，最终是否有一个底层 C 库可以操作一种 FILE * 对象，并具有一个兼容的 fclose() 实现。
至少在 MacOS 和 Linux 下，所有这些问题的答案很可能都是"is"。根据我的经验，很难将两个不同的、不兼容的 C 库混合在一起；你必须真正努力去做。
附录:不过，我想我应该承认，我的经历可能已经过时了。根据我的经验，在任何类 Unix 系统上，只有一个 C 库，通常是 /lib/libc.{a,so}。但我收集到“现代”编译器倾向于在特殊位置访问他们自己的编译器和特定于版本的库，这意味着您担心的场景可能是个问题。对我来说，这似乎是疯狂的方式，但话又说回来，似乎世界上越来越多的人似乎正在拥抱dependency hell ，而不是试图消除它。
关于c - C 标准库结构在 macOS 或 Linux 上的编译器和库版本之间是否兼容？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48389080/