Разрешить общий путь к библиотеке в системах 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 также специально указывает , а не , чтобы использовать функцию SearchPath для поиска DLL, и не , чтобы использовать флаг DONT_RESOLVE_DLL_REFERENCES, упомянутый в комментариях.

---

Для Linux существует инструмент ldd, для которого доступен исходный код. На самом деле он загружает разделяемые библиотеки, но со специальной переменной окружения LD_TRACE_LOADED_OBJECTS, которая по соглашению заставляет их пропускать что-либо. Поскольку это всего лишь соглашение, помните, что вредоносные файлы могут выполнять действия при загрузке с помощью ldd CVE-2009-5064 .