библиотеки ускорения, построенные с относительными путями

Question

Я построил boost 1.57.0 в QNX 6.5.0. Ошибка сборки отсутствует. Но некоторые библиотеки связаны с libboost_system.so с указанием относительного пути. Я сохранил журналы компиляции. Вот связь шаг boost_thread:

"QCC_gpp" -o "bin.v2/libs/thread/build/qcc/release/threading-multi/libboost_thread.so.1.57.0" -shared "bin.v2/libs/thread/build/qcc/release/threading-multi/pthread/thread.o" "bin.v2/libs/thread/build/qcc/release/threading-multi/pthread/once.o" "bin.v2/libs/thread/build/qcc/release/threading-multi/future.o" "bin.v2/libs/system/build/qcc/release/threading-multi/libboost_system.so.1.57.0" -lm 

Итак, когда я бегу ldd libboost_thread.so, он не может найти libboost_system. Я думаю, что libboost_thread должен быть связан с опцией -lboost_system. Но я не знаю, как это сделать.

Спасибо.

Редактировать: Я не могу построить какую-либо программу, связанную с boost_thread. Потому что, boost_thread ищет boost_system в папке bin.v2/libs/system/build/qcc/release/threading-multi. Однако как boost_thread, так и boost_system находятся в папке поиска библиотеки. (определяется с помощью LD_LIBRARY_PATH)

Answer 1

Если вы запустите objdump -p libboost_thread.so, вы обнаружите, что запись NEEDED для libboost_system.so содержит (относительный) путь. Согласно спецификации ELF, запись NEEDED должна содержать только имя нужной библиотеки, поэтому, похоже, в компоновщике или в QCC появляется ошибка.

Потому что если это произойдет, система не сможет найти файл во время выполнения, если текущий каталог не будет таким же, как при связывании.

Простейший обход - связать статически с libboost_thread.a.

Другая работа вокруг, что я использовал сам, чтобы создать оболочку вокруг QCC, превращающий командную строку так, чтобы зависимости приведены в качестве -Wl,-L <path> -Wl,-l <name> вместо <path>/lib<name>.so Это также требует изменения в системе наддува сборки, так что это Безразлично 't добавьте номер версии в конец имен файлов библиотеки.

Answer 2

Я думаю, вы должны взять библиотеки из промежуточной области.

я обычно есть что-то подобное:

-L /home/.../boost/stage/lib/ -lboost_system 

Конечно, заменяющего /home/.../boost с каталога повышающего

---

Слегка связаны: с указанной выше конфигурации, вам необходимо убедиться, что правильные версии библиотек находятся на пути библиотеки загрузчика (LD_LIBRARY_PATH, ldconfig).

Если вы хотите построить развития, вы можете «просто работать» в системе, вы построили это, вы можете испечь путь к библиотеке прямо в целевой двоичном:

-Wl,-rpath -Wl,/home/.../boost/stage/lib/:/usr/lib/x86_64-linux-gnu 

Answer 3

Как писал Никлас Ангаре, проблема в записи NEEDED содержит относительный путь во время сборки, когда она должна содержать только имя .so-файла.

Это происходит потому, что совместно используемые библиотеки, данные линкер не имеют SONAME и , что происходит потому, что компоновщик не получил возможность -h.

Из ld documentation:

-h имя
-soname = имя
При создании ELF совместно используемого объекта, установить внутреннее поле DT_SONAME с указанным именем. Когда исполняемый файл связан с общим объектом, у которого есть поле DT_SONAME, тогда, когда исполняемый файл запускается, динамический компоновщик будет пытаться загрузить общий объект, указанный в поле DT_SONAME, вместо использования имени файла, указанного компоновщику.

Почему линкер не имеет опции -h для сборки qcc? Это, кажется, давно забывают Повысьте ошибка (см Boost.org ticket, github issue)

Решение, как это было предложено в ссылки выше, чтобы удалить $(HAVE_SONAME) из tools/build/v2/tools/qcc.jam