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

Question

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

copy libfoo.a foo.lib

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

Answer 1

根据几个因素，它可能会也可能不会起作用 - 并且有几个原因。我认为你的意思是全面的，可逆的兼容性。

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

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

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

   不同的C ++编译器对变量和对象名称进行不同的修改，导致“[object]代码...通常不能链接”

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也是具有相同或兼容内容索引的目标文件的存档。