解决Windows和* nix系统上的共享库路径

Question

在加载共享库的名称时，系统会根据搜索顺序或在缓存中搜索某些目录中的实际文件（例如.dll）。

我如何以编程方式获取DLL的解析路径（给定其名称，但没有实际加载它）？例如在Windows上，for kernel32或kernel32.dll它可能会返回，C:\windows\system32\kernel32.dll而给定foo它可能是C:\Program Files\my\app\foo.dll。

如果无法做到这一点，还有另一种方法来确定某些库是否属于系统吗？例如，user32.dll或者libc.so.6是系统库，但avcodec-55.dll还是myhelperslib.so没有。

我对适用于Windows，Linux和Mac OS的解决方案感兴趣。

Answer 1

在Windows上，LoadLibraryEx具有LOAD_LIBRARY_AS_DATAFILE用于在不执行您称为“实际加载”的操作的情况下打开DLL 的标志。

可以将其与任何搜索顺序标志结合使用（是的，不止一个搜索顺序）。

不幸的是，您不能使用GetModuleFilename。使用GetMappedFileName代替。

该LoadLibraryEx文档还明确指出不要使用该SearchPath功能来定位DLL，也不要使用DONT_RESOLVE_DLL_REFERENCES注释中提到的标志。

对于Linux，有一个ldd可用的源代码工具。它实际上确实加载了共享库，但是设置了特殊的环境变量 LD_TRACE_LOADED_OBJECTS，按照约定，这会使它们跳过任何操作。因为这只是一个约定，所以请注意恶意文件在ldd CVE-2009-5064 加载时可以执行操作。