C++ 如何在MSVC中使用MingW编译的库？

我已经用MingW/MSYS编译了几个库。。。生成的静态库始终是.a文件。 当我尝试将库与MSVC项目链接时，Visual Studio会抛出“未解析的外部符号”。。。这意味着，静态库与C++链接器不兼容。我认为它必须转换为MSVC兼容的.lib文件

---

.a和.lib都只是.o或.obj文件的AR归档文件，那么有没有办法在MSVC项目中使用MingW编译的libs？或者我必须在一个编译器/链接器中编译/链接所有内容-仅限MSVC/MingW？ 据说MingW编译器与MSVC兼容

我读了一些关于这个主题的文章，但他们大多说将文件重命名为.lib应该可以完成这项工作，但不幸的是，这对我不起作用

我试图链接的库是用C编写的

MSVC链接器引发如下错误：

error LNK2019: unresolved external symbol "int __cdecl openssl_call(struct ssl_State *,int,int,int)" (?openssl_call@@YAHPAUssl_State@@HHH@Z) referenced in function _main MyAPP.obj

。。。还有4个相同的错误，涉及从我的应用程序调用的其他函数

---

谢谢您的建议。

这些库是兼容的，但前提是您提供了C接口。MSVC和G++使用不同的名称篡改方案，所以不能轻易地将一个C++代码与另一个代码创建的链接连接起来。

< P>根据这个错误，你在一个注释中输入：

---

错误LNK2019:未解析的外部 符号“int\uuu cdecl” openssl_调用（结构ssl_状态 *，int，int，int）“（？openssl_调用@@YAHPAUssl_状态@@HHH@Z) 在函数_mainmyapp.obj中引用 所有其他4个错误仅在以下情况下相同 其他函数名

尝试在openssl的包含文件周围放置

extern“C”

。例如：

extern "C" {
include "openssl.h"
}

---

使用指令将编译器编译为使用C链接，而不是C++，这将阻止它在函数上执行。因此，它将在库中查找函数openssl_调用，而不是？openssl_调用@@YAHPAUssl_状态@@HHH@.

我遇到了在MSVC中使用mingw编译dll的相同情况。我使用以下工具使其工作：
1） 像这样使用gcc：

gcc-shared-o your_dll.dll your_dll_src.c-Wl，--output def，your_dll.def

粗体部分指定gcc将生成一个*def文件，用于编写导出项目的脚本。然后需要使用随MSVC一起分发的lib.exe，例如：

lib/def:your_dll.def

然后，将有一个来自lib.exe的\u dll.lib文件（假设您的\u dll.dll与\u dll.def位于同一目录中）

---

目前，我可以在MSVC项目中使用*.lib并正确链接dll，但出现了运行时错误。无论如何，这样的工作使你的链接可行。

简介

使用不同编译器创建的对象文件和静态库，甚至使用同一编译器的不同版本创建的对象文件和静态库，通常无法链接在一起。这个问题不是MinGW特有的：许多其他编译器是互不兼容的。如果可以的话，从源代码使用相同版本的编译器构建所有内容

Dll略有不同。有时，您可以将使用一个编译器构建的DLL链接到使用另一个编译器编译的应用程序。如果DLL是用C编写的，即使应用程序是用C++编写的，这也是很好的。例如，MinGW C++程序通常链接到提供Windows的C运行库。在C++中编写的DLL也可以工作，只要通过与外部“C”声明的C接口与它们通信即可。否则，可能会出现链接错误，因为不同的编译器会对C++名称进行不同的修改。 为什么不同的编译器不能互操作

有时人们想知道为什么编译器编写者不使用相同的名称损坏方案。这可能会使链接成功，但很可能会使程序在调用DLL时崩溃。真正的链接兼容性需要一个通用的应用程序二进制接口，名称混乱只是众多考虑因素之一。以下是部分列表：--

• 根据本页，一个编译器提供3200个不同的ABI：
• 根据Stroustrup（ARM，7.2.1c，第122页）：

如果两个C++实现相同的系统使用不同的调用 序列，或在其他方面是不兼容的链接，这将是 使用类型签名的相同编码是不明智的

传统上，实现者故意使用不同的名称篡改方案，他们认为在链接时说“不”比让一些简单的代码工作并让问题在运行时出现要好

<>虽然GNUG++可以链接MSVC C++库，可以生成MSVC++兼容库/DLL，但这并不意味着它们将由于C++的动态特性而在运行时工作。其中一些可能的原因是：--

• 使用显式.def文件可以避免的简单名称损坏问题
• 需要正确的编译器选项（-mms位字段，…）的不同结构对齐问题
• 底层异常和内存模型之间的根本冲突：--

MSVC DLL中的new/delete或malloc/free不会与Cygwin newlib new/delete或malloc/free合作。使用不同的new/malloc根本无法释放在函数中分配的空间

由MSVC DLL引发的异常不会被Cygwin可执行文件捕获，反之亦然

慢速GNU SJLJ异常模型（用于GCC-3.x和更早版本）与MSVC++模型兼容，但新的DWARF2模型（将由GCC-4.x使用）将不兼容

---

<>引用：

我应该做些什么来将MIWW编译的LIB与MSVC编译的可执行文件链接成功？IM连接到库的应用程序是用C++编写的，链接的库是C（它的OpenSSL，ZLIB和XECES）@ NoMeNo4OK，请张贴几个（三或四）个链接错误。