代码之家  ›  专栏  ›  技术社区  ›  NumberFour

如何在MSVC中使用MingW编译的库?

  •  11
  • NumberFour  · 技术社区  · 14 年前

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

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

    我试图链接的库是用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
    

    谢谢你的建议。

    3 回复  |  直到 14 年前
        1
  •  16
  •   shf301    14 年前

    错误LNK2019:未解析的外部 符号“int\u cdecl openssl\u调用(struct ssl\u State *,int,int,int)“(?openssl\u调用@@YAHPAUssl\u状态@@HHH@Z) 在函数MyAPP.obj中引用 其他函数名称

    试着把 extern "C" 在您的周围包括openssl文件。例如:

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

    extern "C" 将指示编译器使用C链接,而不是C++,这将阻止它执行。 name mangling 关于函数。所以它将在库中查找函数openssl\u call,而不是?openssl\u call@@YAHPAUssl\u State@@HHH@.

        2
  •  11
  •   anon anon    14 年前

        3
  •  10
  •   coanor    14 年前

    我遇到了在MSVC中使用mingw编译的dll的相同情况。我使用以下工具使其工作:

    gcc-shared-o your\u dll.dll your\u dll\u src.c -Wl,--output def,您的_dll.def

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

    lib/def:您的\u dll.def

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

        4
  •  5
  •   Amir Saniyan    4 年前

    介绍

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

    为什么不同的编译器不能互操作

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

    序列,或在其他方面是不兼容的链接,这将是 使用类型签名的相同编码是不明智的。

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

    • 简单的名称损坏问题,可以通过显式的.def文件来避免。
    • 不同的结构对齐问题需要正确的编译器选项(-mms位域,…)。
    • 基本异常和内存模型的根本冲突:--
    1. MSVC DLL中的new/delete或malloc/free不会与Cygwin newlib new/delete或malloc/free合作。使用不同的new/malloc根本无法释放在函数中分配的空间。
    2. 由MSVC DLL引发的异常不会被Cygwin可执行文件捕获,反之亦然。
    3. 慢gnusjlj异常模型(用于GCC-3.x和更早版本)与MSVC++模型兼容,但是新的DWARF2模型(将由GCC-4.x使用)将不兼容。

    参考文献: http://www.mingw.org/wiki/Interoperability_of_Libraries_Created_by_Different_Compiler_Brands