Про сборку, rpath и всё такое

Нетривиальные программы имеют свойство иметь зависимости на библиотеки. Чаще всего библиотеки эти системные, и магия линкера [см. Ulrich Drepper, DSO] решает проблемы нахождения этих библиотек. Но в случае, когда при разработке программы принимается решение выделить часть кода в виде .so, начинается интересное.

Часть 0. Отсутствие rpath

Обычно по началу rpath не используется и о нм даже не подозревают. Ситуация усугубляется тем, что под windows текущий каталог входит в library search path (и, к счастью, теперь он входит туда последним, а не первым, [сслка?]). Поэтому немногие подозревают, что если собрать библиотеку, собрать приложение и попытаться запустить последние, то оно не запустится, так как библиотеку не найдёт. Самые нестойкие на этом моменте откатываются на статическую линковку и не зарекаются о динамической линковке со своими библиотеками больше никогда. Более настойчивые таки открывают справку по линкеру и узнают про runtime library search path.

Часть 1. LDFLAGS += -Wl,-rpath=`pwd`

Добавив магические опции -Wl,-rpath=pwd («Кто вообще придумал этот синтаксис?»), приложение с библиотекой таки удаётся запустить. Проблема решена! На самом деле нет.

Часть 2. \\\\\$$ORIGIN

Проект развивается, количество библиотек растёт. Но как только возникает необходимость переложить куда-то собранные файлы (для переноса на стенд за полчаса до презентации), возникает проблема: приложение опять не может найти библиотеки! Все мейкфайлы срочно перековыриваются на использование статической линковки, чтобы таки иметь возможность показать хоть что-то.

После того, как аврал спадает, таки удаётся добраться до документации на линкер (или stackexchange) и узнать, что можно задавать относительные пути через параметр $ORIGIN, который раскрывается runtime linker'ом в путь до загружаемого файла. Главное — не забыть его достаточно старательно заэскейпить, чтобы он дошёл в этом виде сквозь make с его eval'ами и shell.

Часть 3. Bundled vs distribution libraries

Часть 4. make install INSTALL_PREFIX=install_root

Часть 5. dpkg-buildpackage

На данный момент скрипты сборки поддерживают следующие конфигурации:

• Сборка с системными библиотеками — никаких специальных упражнений, библиотеки находятся по «стандартным» путям ()
• Сборка с собственными библиотеками —

Как нам помогают с этим жить системы конфигурации сборки?

Никак. CMake облегчает поиск системных библиотек (и то не всегда и не всегда правильно), Autotools не решает и этого (зато он реш)

• libtool