不同的MinGW-w64版本破坏了DLL的加载

如何解决不同的MinGW-w64版本破坏了DLL的加载

我有一个开源游戏项目，该项目主要是在Ubuntu下开发的。最近，我将其移植到Windows中，只进行了一些细微的调整，然后将其构建为Windows，因为我只使用了跨平台的库和功能。

要构建它，最初我是使用Ubuntu 19.04存储库中的MinGW-w64进行交叉编译的，它的工作原理很吸引人。这是它报告的版本：

$ x86_64-w64-mingw32-g++-posix --version
x86_64-w64-mingw32-g++-posix (GCC) 9.2-posix 20191008
Copyright (C) 2019 Free Software Foundation,Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

当我更新到Ubuntu 20.04时，MinGW-w64的版本号有所增加：

$ x86_64-w64-mingw32-g++-posix --version
x86_64-w64-mingw32-g++-posix (GCC) 9.3-posix 20200320
Copyright (C) 2019 Free Software Foundation,Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

此更新破坏了我的版本，因为新版本的MinGW-w64生成的可执行文件不起作用。在Windows机器上执行时，无法从其DLL依赖项中找到符号，并且出现以下弹出错误：

应将错误消息翻译为英文版（填充变量）：

glome.exe-找不到入口点

过程入口点ogg_page_bos不在动态链接库«glome.exe的路径»中。

这里需要注意的有趣点是：

• 它将glome.exe视为DLL，这与我在网上发现的所有错误实例不同，后者将可执行文件放在标题上，但将实际的DLL放在消息正文中；
• 所需的符号可以在伴随文件libogg-0.dll中找到；
• 如果我在带有Wine的Linux上运行它，那么它会起作用；
• 如果我将二进制glome.exe换成Ubuntu 19.10内置的二进制文件，它将起作用；
• 两个版本（Ubuntu 19.10和Ubuntu 20.04）都使用由CMake生成的完全相同的编译器参数。

这是用于编译游戏文件之一的命令行（有很多文件，但是所有文件都以相同的方式编译）：

cd /home/lucas/glome/ubuntu-20.04-win-build/src/sdl && /usr/bin/x86_64-w64-mingw32-g++-posix   @CMakeFiles/glome.dir/includes_CXX.rsp -march=haswell -mtune=generic -Ofast -fno-fat-lto-objects -flto=12 -I/home/lucas/glome/windows-deps/opusfile/include/opus/ -I/home/lucas/glome/windows-deps/opus/include/opus/ -I/home/lucas/glome/windows-deps/libogg/include/ogg/ -I/home/lucas/glome/windows-deps/glew-2.1.0/include/ -I/home/lucas/glome/windows-deps/OpenAL-1.1-SDK/include -I/home/lucas/glome/windows-deps/libogg/include -I/home/lucas/glome/windows-deps/SDL2-2.0.12/include/ -I/home/lucas/glome/windows-deps/boost_1_72_0/ -g   -std=gnu++17 -o CMakeFiles/glome.dir/input.cpp.obj -c /home/lucas/glome/src/src/sdl/input.cpp

其中CMakeFiles/glome.dir/includes_CXX.rsp仅包含-I指令：

-I/home/lucas/glome/src/src/common/. -I/home/lucas/glome/src/external/concurrentqueue -I/home/lucas/glome/ubuntu-20.04-win-build/src -I/home/lucas/glome/src/src/sdl

可执行文件的链接命令为：

/usr/bin/x86_64-w64-mingw32-g++-posix -march=haswell -mtune=generic -Ofast -fno-fat-lto-objects -flto=12 -I/home/lucas/glome/windows-deps/opusfile/include/opus/ -I/home/lucas/glome/windows-deps/opus/include/opus/ -I/home/lucas/glome/windows-deps/libogg/include/ogg/ -I/home/lucas/glome/windows-deps/glew-2.1.0/include/ -I/home/lucas/glome/windows-deps/OpenAL-1.1-SDK/include -I/home/lucas/glome/windows-deps/libogg/include -I/home/lucas/glome/windows-deps/SDL2-2.0.12/include/ -I/home/lucas/glome/windows-deps/boost_1_72_0/ -g   -Wl,--whole-archive CMakeFiles/glome.dir/objects.a -Wl,--no-whole-archive  -o glome.exe -Wl,--out-implib,libglome.dll.a -Wl,--major-image-version,--minor-image-version,0 @CMakeFiles/glome.dir/linklibs.rsp

其中CMakeFiles/glome.dir/linklibs.rsp包含：

../common/libcommon.a -lopengl32 -lglu32 -march=haswell -mtune=generic -Ofast -fno-fat-lto-objects -flto=12 -I/home/lucas/glome/windows-deps/opusfile/include/opus/ -I/home/lucas/glome/windows-deps/opus/include/opus/ -I/home/lucas/glome/windows-deps/libogg/include/ogg/ -I/home/lucas/glome/windows-deps/glew-2.1.0/include/ -I/home/lucas/glome/windows-deps/OpenAL-1.1-SDK/include -I/home/lucas/glome/windows-deps/libogg/include -I/home/lucas/glome/windows-deps/SDL2-2.0.12/include/ -I/home/lucas/glome/windows-deps/boost_1_72_0/ /home/lucas/glome/windows-deps/OpenAL-1.1-SDK/libs/Win64/OpenAL32.lib /home/lucas/glome/windows-deps/glew-2.1.0/lib/Release/x64/glew32.lib /home/lucas/glome/windows-deps/opusfile/lib/libopusfile.a /home/lucas/glome/windows-deps/opus/lib/libopus.dll.a /home/lucas/glome/windows-deps/libogg/lib/libogg.dll.a -L/home/lucas/glome/windows-deps/SDL2-2.0.12/lib/x64/ -lSDL2main -lSDL2 -static-libgcc -static-libstdc++ -Wl,-allow-multiple-definition -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

除了路径（ubuntu-20.04-win-build和ubuntu-19.10-win-build）之外，编译和链接命令是完全相同的，它们是使用相同的参数从相同的CMakeLists.txt生成的。

问题：

• 为什么Ubuntu 20.04构建可以在Wine上运行，但不能在Windows上运行，而Ubuntu 19.10构建却可以在两者上运行？
• 如何修复Ubuntu 20.04构建以在Windows上运行？

解决方法

在mingw-w64 IRC通道中闲逛之后，那里的人建议我在依赖项跟踪器中打开可执行文件，这突出显示了工作二进制文件和损坏的二进制文件之间的巨大区别：它看起来像符号要求从一个DLL“泄漏”到另一个DLL中，无关的DLL。

是什么促使人们进一步了解DLL导入库。特别是，我通过它们的MSVC生成的导入库链接了某些DLL，即：glew32.lib，OpenAL32.lib和SDL2.lib。

似乎GNU ld在处理来自MSVC的导入库时遇到麻烦，并且此修复程序只是直接链接到DLL文件，在这种情况下，符号加载代码由ld本身生成（并且实际上是受支持的操作要好得多：如果可能，请始终直接链接到.dll，GNU工具链中不需要导入库。

我不知道为什么会这样，显然，在我使用的版本中，GNU ld中存在一个回归。