Почему делают некоторые файлы рабочих пакетов возвращаются “не найденный” для некоторых библиотек вывода ldd?
Я изменил бы несколько вещей о.
find_code() {
# assign all arguments (not just the first ${1}) to MATCH
# so find_code can be used with multiple arguments:
# find_code errorCode
# find_code = 1111
# find_code errorCode = 1111
MATCH="$@"
# For each file that has a match in it (note I use `-l` to get just the file name
# that matches, and not the display of the matching part) I.e we get an output of:
#
# srcdir/matching_file.c
# NOT:
# srcdir/matching_file.c: errorCode = 1111
#
grep -lr "$MATCH" ${SRCDIR} | while read file
do
# echo the filename
echo ${file}
# and grep the match in that file (this time using `-h` to suppress the
# display of the filename that actually matched, and `-n` to display the
# line numbers)
grep -nh -A5 -B5 "$MATCH" "${file}"
done
}
Прямой (возможно, очевидный) ответ заключается в том, что путь поиска для библиотек, которые вы смотрите с LDD , не включают в себя каталоги, где расположены собственные зависимости библиотеки. Обычно, если зависимости библиотеки не обнаружены в системных стандартных местах, библиотека должна была быть построена с указанным путем прогона (с помощью переменной среды $ ld_run_path или соответствующая опция линкера). В противном случае библиотеки не будут найдены позже во время выполнения, так как вы нашли с LDD .
Так почему же Whunderbird работает в любом случае, несмотря на эту «проблему»?
Есть несколько способов того, что необходимые библиотеки могут быть найдены в любом случае, несмотря на отсутствующий путь прогона:
- Переменная среды
$ ld_library_pathустанавливается во время выполнения и поставляет список дополнительных каталогов для поиска. - Нужный каталог может быть включен в путь поиска, потому что он был найден в пути прогона какой-либо другой неравной библиотеки, которая произошла, чтобы загружена Текущий. Кстати, я не уверен, что это работает как несчастный случай внедрения, если стандарт указывает его. Так или иначе, он хрупкий, потому что он важно зависит от точного порядка, в котором загружаются библиотеки.
- Библиотека, возможно, была загружена вручную приложением, используя функцию
DLOPEN (), заданную полный путь.
Thunderbird, кажется, использует последние из этих методов. Я посмотрел на вспышку . Выход из того, что он делает при запуске, и, похоже, это делает это:
- Найдите каталог, откуда приходит собственный двоичный файл. Это всегда возможно, потому что сценарий оболочки, который запускает Thunderbird, делает это с полным ударом.
- Откройте текстовый файл
DEGEDUNDLIBS.LIST, найденный в этом каталоге. - Для каждого имени файла в этом текстовом файле, в порядке, добавьте тот же каталог, чтобы сформировать имя полного пути, и загрузить это в качестве библиотеки, используя
DLOPEN (). - Теперь все эти зависимые библиотеки, такие как
libldap60.so, которые вы упомянули, «предварительно загруженные», и другие библиотеки, которые требуют, чтобы они не должны их найти еще раз.
Обратите внимание, что порядок или файлы, перечисленные в DEGNEDUNDLIBS.LIST .
Причина Thunderbird делает это так, чтобы каталог, в котором он расположен, не должен быть закреплен в приложении или в путь прогона любого из его внутренних библиотек.
Я не знаю, что делает Java, но это без сомнения, что-то похожее.