【问题标题】:Crash on jmpq to a function in another dll with mingw64使用 mingw64 在 jmpq 上崩溃到另一个 dll 中的函数
【发布时间】:2015-02-03 13:45:15
【问题描述】:

我正在使用 mingw64 在 Windows 上将我的项目从 32 位迁移到 64 位。

一切都在编译/链接正常,但是我在运行时遇到了一些问题:调用另一个 DLL 中引用的函数时程序崩溃,例如在这样的指令上:

0x574040   ff 25 e8 66 6a 00   jmpq *0x6a66e8(%rip)   # 0xc1a72e <_ZN12QTableWidget18currentCellChangedEiiii+638>

上面的例子是一个 Qt 函数,在启动应用程序时调用,但我在使用其他 DLL 时也有类似的问题。

奇怪的事情:我只在发布模式下遇到了 Qt DLL 的问题(这意味着我使用了另一组名称以“d”结尾的 DLL)。

在调试模式下,我也有类似的问题,但只有一个库。有了这个库,我可以动态加载函数(使用QLibrary),所以DLL 似乎不会无效。

我花了一整天的时间试图找出问题所在,但我没有其他想法:

  • DLL 和 exe 文件在 objdump 时被视为“文件格式 pei-x86-64”。
  • 应该是用同一个编译器编译的(除了我提到的用 MSVC 编译但只有 C 接口的附加库)
  • DLL 文件实际上存在于 exe 文件旁边(否则我会遇到有意义的错误“X.DLL 正在从您的计算机发送消息”)。

如果有人有任何线索,请告诉我!

【问题讨论】:

  • 这篇文章帮助了我:stackoverflow.com/questions/24641898/… 和这篇文章:stackoverflow.com/questions/3573475/… 尝试链接 dll 直接解决了这个问题。但我想知道为什么使用 .lib 不起作用,而它使用 32 位。此外,对于 Qt,由于一切都是自动生成的,我不能真正强制链接到 dll 文件。所以我仍然很想知道为什么像往常一样使用 .lib 不起作用。

标签: c++ windows mingw-w64


【解决方案1】:

好的,确实有问题:

  • 对于使用 MSVC 编译的附加库,it is not possible to link against .lib 是一个已知问题。正如 cmets 中所说,gcc 可以直接链接到 DLL,从而为我解决了这个 lib 的问题。
  • 我在发布模式下使用其他库时遇到问题,但这是一个完全不同的问题:我正在使用的软件具有保护机制,仅在发布模式下激活,这会搞砸一切。

【讨论】:

    猜你喜欢
    • 2022-06-11
    • 2018-08-04
    • 2011-04-17
    • 1970-01-01
    • 2016-08-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-10-05
    相关资源
    最近更新 更多