Динамическая зависимость lib / tls путь поиска

У меня есть исполняемый файл, который зависит от двух основных библиотек повышения, libboost_system а также libboost_threadи когда исполняемый файл загружает библиотеки, путь поиска сбивается с толку lib/tls:

 $ LD_DEBUG=libs ./var.exe
25130:     find library=libboost_system.so.1.55.0 [0]; searching
25130:      search path=/opt/boost_1_55_0/stage/lib/tls/x86_64:/opt/boost_1_55_0/stage/lib/tls:/opt/boost_1_55_0/stage/lib/x86_64:/opt/boost_1_55_0/stage/lib         (RPATH from file ./var.exe)
25130:       trying file=/opt/boost_1_55_0/stage/lib/tls/x86_64/libboost_system.so.1.55.0
25130:       trying file=/opt/boost_1_55_0/stage/lib/tls/libboost_system.so.1.55.0
25130:       trying file=/opt/boost_1_55_0/stage/lib/x86_64/libboost_system.so.1.55.0
25130:       trying file=/opt/boost_1_55_0/stage/lib/libboost_system.so.1.55.0
25130:
25130:     find library=libboost_thread.so.1.55.0 [0]; searching
25130:      search path=/opt/boost_1_55_0/stage/lib            (RPATH from file ./var.exe)
25130:       trying file=/opt/boost_1_55_0/stage/lib/libboost_thread.so.1.55.0

Исполняемый файл был связан с точно таким же -rpath=/opt/... настройки для обеих библиотек, и я знаю, что повышение было построено с помощью общего вызова b2 (то есть точно такие же параметры командной строки для обоих). /etc/ld.so.cache не имеет связанных записей.

Кроме того, не кажется, что в самих собранных библиотеках есть что-то примечательное с точки зрения требований rpath или ABI,

$ readelf -d /opt/boost_1_55_0/stage/lib/libboost_system.so.1.55.0 | grep -i rpath
# empty
$ eu-readelf -h /opt/boost_1_55_0/stage/lib/libboost_system.so.1.55.0
# there is no difference in ABI versions

Обе библиотеки имеют одинаковые зависимости общих библиотек, за исключением того факта, что libboost_thread зависит от libboost_systemи обоим нужно GLIBC_2.2.5.

Я считаю, что решено, что libboost_system почему-то нужны ссылки с NPTL Glibc и вот почему <rpath>/lib/tls ищется, но это не очевидно для меня, глядя на objdump libboost_system библиотека, почему это так.

Как помечена библиотека NPTL? Как dlopen (3) решает посмотреть путь lib / tls?

1

Решение

путь поиска непонятно отличается от lib / tls

Вы лаете не на то дерево.

Загрузчик GLIBC принимает RPATH из вашего исполняемого файла, и добавляет PLATFORM строки (tls/x86_64:tls:x86_64 здесь) к нему построить полный путь поиска.

Как только загрузчик обнаружит, что, например, RPATH/tls каталог не существует, он удаляет эту запись из пути поиска (нет смысла многократно искать несуществующий каталог). В конце концов вы просто RPATH само присутствие.

Если вы связываете свой бинарный файл, например, с инвертировать порядок зависимости от libboost_thread а также libboost_systemвы обнаружите, что снова только первая библиотека ищется в RPATH/tlsи т. д. а второй только в RPATH,

0

Другие решения


По вопросам рекламы [email protected]