为何MinGW需正确设置运行时库路径？Windows/Linux差异及无PATH解决方案

差异原因 #

• Linux的ELF可执行文件格式支持rpath（运行时搜索路径）：MinGW在Linux环境下构建时，默认会将依赖库的绝对路径嵌入到可执行文件的rpath字段中，ldd命令能直接读取这些路径，运行时系统会优先按此路径查找库，因此可执行文件能在任意路径运行。
• Windows的PE可执行文件格式没有rpath机制：系统查找DLL的顺序是固定的——当前可执行文件所在目录→系统目录→PATH环境变量中的目录。MinGW在Windows下构建时，不会将自定义库的构建路径写入可执行文件，因此如果DLL不在上述默认搜索路径内，运行时就会弹出“缺少*.dll”错误。

无需修改PATH的解决办法 #

1. 构建时自动复制DLL到可执行文件目录 #

通过CMake的add_custom_command实现构建后自动复制依赖DLL到exe所在目录，这是最常用的方案：

# 假设自定义库目标为mylib，可执行文件目标为myexe
add_custom_command(TARGET myexe POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy_if_different
    $<TARGET_FILE:mylib>  # 获取库的生成路径
    $<TARGET_FILE_DIR:myexe>  # 获取可执行文件的输出目录
)

每次构建完成后，DLL会被自动同步到exe同目录，运行时系统会优先查找当前目录的DLL，无需修改PATH。

2. 改用静态库编译 #

如果不需要动态链接的特性，可将自定义库编译为静态库，把库代码直接嵌入可执行文件，彻底消除DLL依赖：

# 将SHARED改为STATIC，构建静态库
add_library(mylib STATIC src/mylib.cpp)

注意：该方法仅适用于自定义库，若依赖第三方动态库则无法规避其DLL依赖。

3. 利用MinGW的rpath模拟特性 #

MinGW对Windows PE格式有限支持类rpath的功能，通过链接选项指定$ORIGIN（代表可执行文件所在目录），让系统优先在exe目录及其子目录查找DLL：

# 给可执行文件添加链接参数，指定优先查找自身所在目录的DLL
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--rpath,$ORIGIN")
# 如果DLL放在exe的子目录（如libs），可改为：
# set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--rpath,$ORIGIN/libs")

该方案适合需要将DLL与exe分目录存放的场景。

4. 延迟加载DLL并手动指定路径 #

通过MinGW的延迟加载链接选项，让程序启动时不立即加载DLL，而是在代码中手动指定DLL路径后再加载：

# 给可执行文件添加延迟加载选项
target_link_options(myexe PRIVATE -Wl,--delay-load,mylib.dll)

然后在C++代码中通过LoadLibrary指定DLL的绝对路径加载，适合需要动态切换DLL版本的特殊场景，但实现相对繁琐。

内容的提问来源于stack exchange，提问作者joaocandre