问题标签 [dlltool]

我最近发现我编写的在 Windows 上编译 HDBC-postgresql 的指令不再适用于 Haskell 平台 2012.2.0.0。该库构建正常，但是在尝试链接构​​建的库时，cabal失败并显示：

我尝试使用 重新制作libpq.a，dlltool --no-idata4 --no-idata5但随后错误消息更改为Unknown PEi386 section name `.idata$7'.

这似乎是GHC 错误 7103。

根据PE 和 COFF 规范，美元符号包含在部分名称中时具有特殊含义，表示“分组部分”。链接器应该丢弃 "$" 和它后面的所有字符以创建一个合并的.idata部分，其中 "$" 后面的字符用于确定对合并部分的贡献的顺序。

有没有办法强制dlltool不输出分组部分？

或者，有没有办法获取 GNU 存档（A 文件），合并所有分组的部分，并输出生成的合并导入库（imlib）？

编辑： Haskell Platform 2012.4.0.0 也会发生同样的错误。

EDIT2查看的源代码后dlltool，似乎没有办法强制它不输出分组部分。此外，我还没有找到一个现成的实用程序，它将合并目标文件中的分组部分。

出于赏金和这个问题的目的，我将其更改为：如何在.idata给定模块定义 (DEF) 文件的情况下构造单个部分。

我们如何获取带有参数和返回类型的 DLL 文件的导出函数列表？我不知道 DLL 是用哪种语言构建的。我尝试了所有关于 DLL 的工具，但没有工具给出带有参数和返回类型的特定列表。

第 1 步。我有一个用于导出一些符号的可执行文件 ( main.exe ) 的导入库文件 ( main.lib )。使用 extern "C" 导出的那些符号。

第 2 步。我还有一个源文件 ( extra.cpp )，它导出了一些额外的功能。我从中生成了一个静态链接库（extra.lib），并将main.lib包含在其中，因为这些额外功能是main.exe导出的用户。

步骤 3.构建了一个与该库 ( extra.lib ) 链接的 dll ( bbb.dll )，以从main.exe调用这些额外的函数。（请注意，bbb.dll首先由main.exe加载和使用。）

现在我尝试使用 Mingw(gcc) 而不是 MS Visual Studio(cl) 重复步骤 2 和 3。我们称之为步骤 2x 和 3x。由于 main.exe 是一个包含许多文件的大项目......从源代码构建libmain.a不是一个好的选择，我在这里发现main.lib可以使用以下命令转换为 .a 文件：

步骤 2x。

步骤 3x。

我在第 3 步时遇到链接器错误。

这是一个名称修饰差异问题吗？

或者甚至可以以这种方式使用 gcc构建bbb.dll吗？

我做错了什么？

我在 Windows 7 上使用 Visual Studio 2012。MinGW 和 gcc 4.6.1。

检查“A_Function_In_main”是否在 libmain.a 中：

libmain_dump.txt 中关于“A_Function_In_main”的文本块

我正在寻找有关 dlltool 的 --add-indirect 选项的更多信息。你什么时候使用这个选项？它有什么作用？

来自 binutils 的有关此选项的帮助信息：

指定当dlltool创建导出文件时，它应该添加一个允许在不使用导入库的情况下引用导出函数的部分。不管这意味着什么！

我正在尝试使用 MinGW dlltool 构建静态库，以便将其链接到 GCC 中。我所拥有的只是一个 DLL 文件。我创建了一个 *.def 文件，现在我正在尝试制作 *.a 文件。但是我不能强制 MinGW dlltool 创建 antyhing，它只会创建一个空文件。这是控制台输出：

有什么问题？如何创建静态库文件？

使用dlltool -y它可以为现有的 .dll 或 .def 文件创建延迟导入库。这似乎工作得很好，直到在没有相应 dll 的系统上需要 dll （正如延迟导入/加载的 dll 所预期的那样）。但是，我找不到有关如何捕获延迟加载期间生成的错误（缺少模块或缺少函数）的任何信息。

在 MSVC 上，您将使用__try {} __except (...) {}SEH 异常处理，但是，这在 MinGW 上不可用（我也不知道 dlltool 使用哪种异常机制）。

常规try {} catch(...) {}也不起作用（应用程序崩溃的方式与没有任何异常处理的方式相同）。

GDB 输出也不是特别有用：

如果我没记错的话，RaiseException 中发生的未知异常似乎表明了 SEH 异常。

因此，问题是，有没有人成功处理 MinGW-w64 中的延迟加载以及如何处理？

编辑：经过一些实验，我想出了以下解决方案：

但是，我不确定这段代码的行为是否定义明确（毕竟我是从处理程序中跳出来的）。而且看起来也不是特别干净。

编辑2：我尝试了一种不同的方法，设置__pfnDliFailureHook2：

此方法失败，因为异常没有正确传播并导致0x20474343SEH 异常。似乎有一个相关的 GCC 错误应该修复，但至少使用 MinGW-w64 g++ 4.9.2 这仍然失败（这是可用的最新版本）

我无法构建 libpythonX.a。

我收到以下错误dlltool.exe：def 文件 python27.def:0 中的语法错误

我一直在遵循http://sebsauvage.net/python/mingw.html第 2 节上的步骤。

我正在使用 MinGW32，python 32 位。

有人对我缺少什么有任何想法吗？

我正在尝试在 Windows 7 x64 上构建 64 位版本的libpython27.afrom 。python27.dll

按照这些说明，我尝试了：

有什么可以解释的Fatal error: no compiled in support for x86_64？

我懂了：

问题是否来自事实possible <machine>不包含x86_64，如果是，在哪里找到dlltool.exe支持的x86_64？

我正在尝试在 Windows 7 x64 上构建 64 位版本的libpython27.afrom 。python27.dll

按照这些说明，我尝试了：

有什么可以解释的dlltool: Can't create .lib file: libpython27.a: Invalid bfd target？

dll工具版本：

通过以下示例，我一直在研究延迟加载（delayimp）管道作为 Windows 上缺少的 RPATH 功能的可能后端：

GNU 和 LLVM 都使用“dlltool”类似地实现延迟加载（然而，LLVM 的 dlltool 似乎已合并到“ld-link”中）。本质上，在 LLVMlld/COFF/DLL.cpp或 BinUtil中执行的任务dlltool.c有两个：

1. 为延迟加载函数生成跳转表存根（参见下面的示例）
2. 生成应部署 __delayLoadHelper2 代码的蹦床（请参见下面的示例）

成功绑定后， __delayLoadHelper2似乎将解析的函数地址直接写入可执行代码部分：

为了对可执行映像进行修改，微软开发了一些花哨的功能，可以临时将写入权限添加到相应的内存区域。

现在的问题是：要修改的代码在进入“.idata”部分的跳转表存根中，并且无法获得写入权限：

因此，目前硬绑定不起作用，并给出“写访问冲突”。我想知道我在这里缺少哪种二进制配置？

我的测试配置：来自 github 的 LLVM 上游，来自 git 的 BinUtils，MSVC2019，Windows 7。