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

Question

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

我如何以编程方式获取DLL的解析路径（给定其名称，但没有实际加载它）？例如。在Windows上，对于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文档还明确指出 not 使用SearchPath函数来定位DLL，而 not 使用DONT_RESOLVE_DLL_REFERENCES评论中提到的标志。

---

对于Linux，现有的工具ldd可以使用其源代码。它实际上确实加载了共享库，但是设置了特殊的环境变量LD_TRACE_LOADED_OBJECTS，按照约定，它们会跳过所有操作。因为这只是一个约定，所以请注意malicious files can perform actions when loaded by ldd CVE-2009-5064。