之所以想搞明白这个是因为之前写的qt项目release版本和debug版本执行效果不一样

所以想弄明白

主要参考了这个博客，感觉说的比较明白，然后下面是我读自己想要的部分进行提取的

https://www.cnblogs.com/tocy/p/windows_dll_searth_path.html

首先，你的exe文件在编译的时候指定了它需要哪些部分的dll文件，在应用程序加载dll的时候如果加载错（同名）了dll就会报错

接下来的内容是

1. 参考MSDN，给出Windows下DLL查找顺序

2. 简单使用ProcessMonitor来验证DLL查找顺序

1

应用程序可以通过以下方式控制一个DLL的加载路径：

• 使用全路径加载、
• 使用DLL重定向
• 使用manifest文件。

如果上述三种方式均未指定，系统查找DLL的顺序将按照本部分描述的顺序进行

对于以下两种情况的DLL，系统将不会查找，而是直接加载：

对于已经加载到内存中的同名DLL，系统使用已经加载的DLL，并且忽略待加载DLL的路径。（注意对某个进程而言，系统已经加载的DLL一定是唯一的存在于某个目录下。）

b. 如果该DLL存在于某个Windows版本的已知DLL列表（unkown DLL）中，系统使用已知DLL的拷贝（包括已知DLL的依赖项）。已知DLL列表可以从如下注册表项看到：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs。

这里有个比较坑的地方，对于有依赖项的DLL（即使使用全路径指定DLL位置），系统查找其所依赖DLL的方法是按照实际的模块名称来的，因此如果加载的DLL不在系统查找顺序目录下，那么动态加载该DLL（LoadLibrary）会返回一个"找不到模块"的错误。

2. 系统标准DLL查找顺序

系统使用的标准DLL查找顺序依赖于是否设置了"安全DLL查找模式"（safe DLL search mode）。"安全DLL查找模式"会将用户当前目录置于查找顺序的后边。

"安全DLL查找模式"默认是启用的，禁用的话，可以将注册表项HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode设为0。调用SetDllDirectory函数可以禁用"安全DLL查找模式"，并修改DLL查找顺序。

Windows XP下，"安全DLL查找模式"默认是禁用的，需要启用该项的话，在注册表中新建一个SafeDllSearchMode子项，并赋值为1即可。"安全DLL查找模式"从Windows XP SP2开始，默认是启用的。

启用"安全DLL查找模式"时，查找顺序如下：

a. 应用程序所在目录；

b. 系统目录。GetSystemDirectory返回的目录，通常是系统盘\Windows\System32；

c. 16位系统目录。该项只是为了向前兼容的处理，可以不考虑；

d. Windows目录。GetWindowsDirectory返回的目录，通常是系统盘\Windows；

e. 当前目录。GetCurrentDirectory返回的目录；

f. 环境变量PATH中所有目录。

如果"安全DLL查找模式"被禁用，查找顺序如下：

a. 应用程序所在目录；

b. 当前目录。GetCurrentDirectory返回的目录；

c. 系统目录。GetSystemDirectory返回的目录，通常是系统盘\Windows\System32；

d. 16位系统目录。该项只是为了向前兼容的处理，可以不考虑；

e. Windows目录。GetWindowsDirectory返回的目录，通常是系统盘\Windows；

f. 环境变量PATH中所有目录。

默认情况下应该是这个：

包含可执行文件的目录。

Windows 的系统目录，该目录可以通过 GetSystemDirectory 得到，一般为 System32 目录，若为 32 位程序跑在 64 位系统下，则为 SysWOW64 目录。

16 位的系统目录，即 Windows 目录中的 System 目录。 Windows 目录，该目录可以通过 GetWindowsDirectory 得到。 进程的当前目录。

PATH 环境变量中所列出的目录。

Windows/Linux链接器加载动态库的搜索路径顺序

如需转载请标明出处：http://blog.csdn.net/itas109
QQ技术交流群：129518033

目录

文章目录

• Windows/Linux链接器加载动态库的搜索路径顺序
• • @[toc]
  • 前言
  • 1.Windows链接器加载动态库的搜索路径顺序
  • 2.Linux链接器加载动态库的搜索路径顺序

系统：Ubuntu 16.04.5 64bit
系统：windows 7 64bit

前言

Windows/Linux程序运行时，其动态库的路径搜索是有顺序的。本文介绍其搜索顺序。

1.Windows链接器加载动态库的搜索路径顺序

通过隐式和显式链接，Windows首先搜索“已知DLL”，例如Kernel32.dll和User32.dll。 Windows然后按以下顺序搜索DLL：

1. 当前进程的可执行模块所在的目录
2. 当前目录
3. Windows系统目录。如C:\Windows\System32，GetSystemDirectory函数检索此目录的路径
4. Windows目录。 如C:\Windows，GetWindowsDirectory函数检索此目录的路径
5. PATH环境变量中列出的目录

英文原文：

Windows then searches for the DLLs in the following sequence:
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.

2.Linux链接器加载动态库的搜索路径顺序

链接器使用以下搜索路径来查找所需的共享库：

1. -rpath-link选项指定的任何目录。

2. -rpath选项指定的任何目录。-rpath和-rpath-link之间的区别在于-rpath选项指定的目录包含在可执行文件中并在运行时使用，而-rpath-link选项仅在链接时有效。

gcc main.c -rpath dir_path

3. 在ELF系统上，对于本机链接器，如果是-rpath和-rpath-link选项未使用，搜索环境变量“LD_RUN_PATH”的内容。 在SunOS上，如果未使用-rpath选项，搜索指定的任何目录使用-L选项。

4. 对于本机链接器，搜索环境变量的内容“LD_LIBRARY_PATH”。

5. 对于本机ELF链接器，共享的“DT_RUNPATH”或“DT_RPATH”中的目录在库中搜索它所需的共享库。 “DT_RPATH”条目是如果存在“DT_RUNPATH”条目，则忽略。

6. 默认目录，通常是/lib和/usr/lib。

7. 对于ELF系统上的本机链接器，如果文件/etc/ld.so.conf存在，则列表在该文件中找到的目录。

如果找不到所需的共享库，链接器将发出警告并且继续链接。

英文原文：

ld - The GNU linker

-rpath-link=dir
           When using ELF or SunOS, one shared library may require another.  This happens when an
           "ld -shared" link includes a shared library as one of the input files.

           When the linker encounters such a dependency when doing a non-shared, non-relocatable
           link, it will automatically try to locate the required shared library and include it
           in the link, if it is not included explicitly.  In such a case, the -rpath-link option
           specifies the first set of directories to search.  The -rpath-link option may specify
           a sequence of directory names either by specifying a list of names separated by
           colons, or by appearing multiple times.

           This option should be used with caution as it overrides the search path that may have
           been hard compiled into a shared library. In such a case it is possible to use
           unintentionally a different search path than the runtime linker would do.

           The linker uses the following search paths to locate required shared libraries:

           1.  Any directories specified by -rpath-link options.

           2.  Any directories specified by -rpath options.  The difference between -rpath and
               -rpath-link is that directories specified by -rpath options are included in the
               executable and used at runtime, whereas the -rpath-link option is only effective
               at link time. Searching -rpath in this way is only supported by native linkers and
               cross linkers which have been configured with the --with-sysroot option.

           3.  On an ELF system, for native linkers, if the -rpath and -rpath-link options were
               not used, search the contents of the environment variable "LD_RUN_PATH".

           4.  On SunOS, if the -rpath option was not used, search any directories specified
               using -L options.

           5.  For a native linker, search the contents of the environment variable
               "LD_LIBRARY_PATH".

           6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared
               library are searched for shared libraries needed by it. The "DT_RPATH" entries are
               ignored if "DT_RUNPATH" entries exist.

           7.  The default directories, normally /lib and /usr/lib.

           8.  For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list
               of directories found in that file.

           If the required shared library is not found, the linker will issue a warning and
           continue with the link.

Refrence：

1. Search Path Used by Windows to Locate a DLL
2. ld on ubuntu
3. Using ld The GNU linker

觉得文章对你有帮助，可以扫描二维码捐赠给博主，谢谢！

如需转载请标明出处：http://blog.csdn.net/itas109
QQ技术交流群：129518033

DLL搜索机制

Windows桌面应用程序可以通过多种方法来控制DLL加载路径：

1. 通过manifest文件指定。
2. DLL重定向技术可以使LoadLibrary 优先在应用程序所在目录查找。
3. 如果上面两种方法都没有使用，则会做下面的检查：
   - 如果同名的DLL已经在内存里，则会直接使用，不会开启搜索。
   - 如果DLL在知名的DLL列表里（在这个注册表下： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs），则会使用这些知名DLL，不会开启搜索。
4. 如果以上条件都没有满足，则会开启DLL搜索。
5. 另外，对于DLL依赖的其他DLL，比如a.dll依赖b.dll，系统会直接用b.dll的名字调用LoadLibrary，而不会加入额外的路径。

DLL标准搜索顺序

DLL标准搜索顺序，分安全搜索模式和非安全搜索模式。默认安全搜索模式是开启的，如果要禁用可以通过创建注册表键值HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**SafeDllSearchMode**并设为0。本文只讨论安全搜索模式。对于非安全搜索模式，可以参考官方文档。

安全模式搜索顺序：

1. 应用程序加载时所在的目录。

2. 系统目录。可以使用GetSystemDirectory获取。

   #include <Windows.h>
   #include <iostream>
   int main() {
       const int MAX_BUFFER_SIZE = 1024;
       wchar_t buffer[MAX_BUFFER_SIZE];
       UINT len = GetSystemDirectoryW(buffer, MAX_BUFFER_SIZE);
       if (!len) {
           std::wcout << "GetSystemDirectory failed with error code: " << GetLastError() << std::endl;
       }
       else
       {
           std::wcout << buffer << std::endl;
       }
       return 0;
   }

输出：
C:\WINDOWS\system32

3. 16位系统目录。

4. Windows目录。使用GetWindowsDirectory获取。

  #include <Windows.h>
  #include <iostream>
  int main() {
      const int MAX_BUFFER_SIZE = MAX_PATH;
      wchar_t buffer[MAX_BUFFER_SIZE];
      UINT len = GetWindowsDirectoryW(buffer, MAX_BUFFER_SIZE);
      if (!len) {
          std::wcout << "GetWindowsDirectory failed with error code: " << GetLastError() << std::endl;
      }
      else
      {
          std::wcout << buffer << std::endl;
      }
      return 0;
  }

输出：

C:\WINDOWS

5. 当前目录。使用GetCurrentDirectory获取。

  int main() {
      const int MAX_BUFFER_SIZE = MAX_PATH;
      wchar_t buffer[MAX_BUFFER_SIZE];
      DWORD len = GetCurrentDirectoryW(MAX_BUFFER_SIZE, buffer);
      if (!len) {
          std::wcout << "GetCurrentDirectory failed with error code: " << GetLastError() << std::endl;
      }
      else
      {
          std::wcout << buffer << std::endl;
      }
      return 0;
  }

这个函数的输出可能和应用程序所在的路径不同。

6. 系统环境变量PATH下的目录。

DLL候补搜索顺序

当使用LoadLibraryEx函数，并且指定LOAD_WITH_ALTERED_SEARCH_PATH标记，以及 lpFileName参数是绝对路径时，会触发DLL候补搜索顺序。候补搜索顺序和标准搜索顺序的区别只在第一条。

安全模式下DLL候补搜索顺序：

1. 参数lpFileName所在的目录。
2. 系统目录。
3. 16位系统目录。
4. Windows目录。
5. 当前目录。
6. 系统环境变量PATH下的目录。

通过调用SetDllDirectory函数也可以改变候补搜索顺序：

1. 应用程序加载的目录。
2. 通过SetDllDirectory添加的目录。
3. 系统目录。
4. 16位系统目录。
5. Windows目录。
6. 系统环境变量PATH下的目录。

自定义搜索顺序

应用程序可以通过指定LoadLibraryEx或SetDefaultDllDirectories函数中不同的搜索标记来自定义搜索顺序。下面是几个常用标记：

1. LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR，DLL所在的目录。
2. LOAD_LIBRARY_SEARCH_APPLICATION_DIR，应用程序目录。
3. LOAD_LIBRARY_SEARCH_USER_DIRS，用户事先通过接口AddDllDirectory或SetDllDirectory指定的一个或多个目录。
4. LOAD_LIBRARY_SEARCH_SYSTEM32， 系统目录。

参考

1. https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
2. https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa