libfoo.a 和 foo.lib 格式是否兼容？

Question

一些构建脚本（例如 numpy 中的那个）只需执行以下操作即可使 gcc 编译的库存档与 Visual Studio 链接器一起工作：

copy libfoo.a foo.lib

令人惊讶的是，它似乎有效。有谁知道为什么？

Answer 1

取决于几个因素，它可能有效，也可能无效 - 并且有几个原因。我认为你的意思是全面的、可逆的兼容性。

1. 对于用于将 DLL 绑定到可执行文件的 implib，答案是否。

   我曾经尝试将 MSVC++ implib 与 gcc 生成的 dll 链接。如果格式 是 兼容的，那么当我重命名库 libfoo.a 时它会起作用。 为了解决这个问题，有一个名为 reimp 的实用程序可以从 DLL 生成合适的 gcc implib。为了逆转这个过程，微软的`lib`工具可以从一个.def文件创建一个静态的implib，如果给定正确的标志，gcc可以用DLL生成它。 [在 mingw 网站上搜索“reimp”了解更多信息]

2. 由于Name Mangling，C++ 编译的目标文件也不兼容。

   不同的 C++ 编译器以不同的方式处理变量和对象名称，导致“[对象] 代码...通常不可链接”

3. 对于编译为普通旧 C 的静态库？ 是的

   我需要更多关于您关心的项目类型的信息，但如果它是 C 并且“copy libfoo.a foo.lib” hack 有效，那么可能就是这种情况。尝试看看这是否适用于 Mingw 或 Dev-C++。 编辑：实际上，这仅在库在 Windows 平台上使用 gcc 编译时才有效（并且它可以双向工作！）。这个 AFAIK 的唯一例外是交叉编译的库——MSVC 拒绝接受它们，至少在 Ubuntu 提供的“i586-mingw32msvc-ar”中是这样。

另一种解释是 MSVC 链接器由于历史原因与 .a 格式兼容。 IIRC，它从 UNIX 时代就已经存在。同样，虽然我只能看到这适用于纯 C，而不是 C++。
编辑：实际上是相反的。 Windows 版本的 GCC 工具包创建与 Microsoft 的 COFF 格式兼容的静态库。

Answer 2

虽然我不知道 lib 格式的任何细节，但我可以提供一些有关 lib*.a 格式的信息。这只是一个 *.o 目标文件的存档，可以使用 ar 程序（binutils 的一部分）进行操作。

prompt>ar t /usr/lib64/libc.a | head
init-first.o
libc-start.o
sysdep.o
version.o
check_fds.o
libc-tls.o
elf-init.o
dso_handle.o
errno.o
errno-loc.o
prompt>ar t /usr/lib64/libc.a | wc
   1447    1447   16904
prompt>

我假设 *.lib 也是具有相同或兼容内容索引的目标文件的存档。