Я хочу знать, где в Linux хранилась информация о файле .so? Ищу libruby.so.2.6. когда я искал в Интернете, ld.so сначала запускает поиск с LD_LIBRARY_PATH, а затем он будет искать файл ld.so.conf и файлы кеша, а затем пути по умолчанию, такие как / lib и / usr / local / lib. В моем случае рубин был установлен в / opt / puppetlabs / puppet / root / bin, и когда я выполнил команду «ldd / opt / puppetlabs / puppet / root / bin», я получил местоположение libruby.so как «/ opt / puppetlabs / марионетка / lib / libruby.so.2.6 ". Теперь я могу получить местоположение общего объекта, но я хотел бы знать, откуда он получил детали.? Я проверил файлы ld_library_path и ld.so.conf, я смог найти эту запись. Итак, кто-нибудь, пожалуйста, помогите мне получить эту информацию
Страница руководства для ldd говорит:
In the usual case, ldd invokes the standard dynamic linker (see
ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set
to 1. This causes the dynamic linker to inspect the program's
dynamic dependencies, and find (according to the rules described in
ld.so(8)) and load the objects that satisfy those dependencies.
Страница руководства для ld дает объяснение правил:
When resolving shared object dependencies, the dynamic linker first
inspects each dependency string to see if it contains a slash (this
can occur if a shared object pathname containing slashes was
specified at link time). If a slash is found, then the dependency
string is interpreted as a (relative or absolute) pathname, and the
shared object is loaded using that pathname.
If a shared object dependency does not contain a slash, then it is
searched for in the following order:
o Using the directories specified in the DT_RPATH dynamic section
attribute of the binary if present and DT_RUNPATH attribute does
not exist. Use of DT_RPATH is deprecated.
o Using the environment variable LD_LIBRARY_PATH, unless the
executable is being run in secure-execution mode (see below), in
which case this variable is ignored.
o Using the directories specified in the DT_RUNPATH dynamic section
attribute of the binary if present. Such directories are searched
only to find those objects required by DT_NEEDED (direct
dependencies) entries and do not apply to those objects' children,
which must themselves have their own DT_RUNPATH entries. This is
unlike DT_RPATH, which is applied to searches for all children in
the dependency tree.
o From the cache file /etc/ld.so.cache, which contains a compiled
list of candidate shared objects previously found in the augmented
library path. If, however, the binary was linked with the -z
nodeflib linker option, shared objects in the default paths are
skipped. Shared objects installed in hardware capability
directories (see below) are preferred to other shared objects.
o In the default path /lib, and then /usr/lib. (On some 64-bit
architectures, the default paths for 64-bit shared objects are
/lib64, and then /usr/lib64.) If the binary was linked with the
-z nodeflib linker option, this step is skipped.