Какой приемлемый метод для развертывания приложения Linux, основанного на общих библиотеках?

Question

У меня есть приложение, которое использует Qt, GDCM и VTK , основной средой сборки является Qt. Все эти библиотеки являются кроссплатформенными и компилируются в Windows, Mac и Linux. Мне нужно развернуть приложение в Linux после развертывания в Windows. Версии vtk и gdcm, которые я использую, являются транковыми версиями от git (примерно месяц назад), более поздние, чем те, которые я могу получить apt-get в Ubuntu 11.04, которая является моей текущей (и единственной) целью развертывания Linux.

Каков принятый метод для развертывания приложения, использующего библиотеки такого типа?

Должен ли я использовать статические ссылки здесь, чтобы избежать LD_LIBRARY_PATH? Я вижу противоречивые сообщения о LD_LIBRARY_PATH; учебные пособия, такие как этот , предполагают, что это «правильный способ» изменить путь к библиотеке для использования общих библиотек через перезагрузку системы. Другие предлагают , чтобы я никогда не устанавливал LD_LIBRARY_PATH. В версии GDCM по умолчанию при установке библиотеки уже помещаются в каталог /usr/local/lib, поэтому эти библиотеки отображаются при запуске ldd <my program>. VTK, с другой стороны, помещает свои библиотеки в /usr/local/lib/vtk-5.9, который не является частью LD_LIBRARY_PATH на большинстве компьютеров пользователя, и поэтому не найден, если в систему не будут внесены некоторые изменения. Копирование файлов VTK в / usr / local / lib не позволяет ldd видеть файлы.

Итак, как я могу заставить мое приложение видеть VTK для использования библиотек?

В Windows развертывание библиотек DLL очень просто, потому что я могу просто включить их в установщик, и приложение находит их, потому что они находятся в локальном каталоге. Этот подход не работает в Linux, поэтому я собирался заставить пользователей устанавливать Qt, GDCM и VTK из любого подходящего источника и использовать местоположения по умолчанию, а затем приложение указывать на эти местоположения по умолчанию. Однако, поскольку VTK помещает вещи в нестандартное место, я должен также ожидать, что пользователи изменят LD_LIBRARY_PATH? Должен ли я включить конкретные версии библиотек, которые мне нужны, а затем выяснить, как заставить исполняемый файл выглядеть в локальном каталоге для этих библиотек и игнорировать те, которые он находит в пути к библиотеке?

Answer 1

Каждое «серьезное» коммерческое приложение, которое я когда-либо видел, использует LD_LIBRARY_PATH.Они неизменно включают сценарий оболочки, который выглядит примерно так:

#!/bin/sh

here="${0%/*}"  # or you can use `dirname "$0"`

LD_LIBRARY_PATH="$here"/lib:"$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
exec "$0".bin "$@"

Они называют этот сценарий примерно как .wrapper и создают дерево каталогов, которое выглядит следующим образом:

.wrapper
lib/  (directory full of .so files)
app1 -> .wrapper (symlink)
app1.bin (executable)
app2 -> .wrapper (symlink)
app2.bin (executable)

Теперьвы можете скопировать все это дерево куда угодно, и вы можете запустить «/ path / to / tree / app1» или «/ path / to / tree / app2 --with --some --arguments», и оно будет работать.То же самое можно сказать о пути / path / to / tree в вашей переменной PATH.

Кстати, именно так Firefox и Chrome делают это более или менее.

Кто бы вам ни сказал, чтобы вы не использовали LD_LIBRARY_PATHИМХО.

Какие системные библиотеки вы хотите поместить в lib, зависит от того, какие версии Linux вы хотите официально поддерживать.

Даже не думайте о статическом линковании.Разработчикам glibc это не нравится, они не заботятся о его поддержке, и им каким-то образом удается сломать его немного сложнее с каждым выпуском.

Удачи.

Answer 2

В общем, лучше всего полагаться на «нормальные» версии библиотек для любого дистрибутива, на который вы нацеливаетесь (и говорят, что вы не поддерживаете диски, которые не поддерживают достаточно недавние версии библиотеки), но если вам ДЕЙСТВИТЕЛЬНО нужно зависеть от передовой версии некоторой разделяемой библиотеки, вы можете связать свое приложение с -Wl,-rpath,'$ORIGIN', а затем установить копию нужной версии в том же каталоге, что и исполняемый файл.

Обратите внимание, что если вы используете make, вам понадобится $$ в make-файле, чтобы получить один $ в аргумент, который фактически отправляется компоновщику. Одиночные койты нужны, чтобы оболочка ничего не гремела ...

Answer 3

Ну, есть два варианта развертывания приложения Linux.

Правильный способ:

• создать пакет для вашего приложения и для библиотек, если онинастолько особенные, что их нельзя установить из стандартных репозиториев

• Существует два основных формата пакетов.RPM и DEB.

Простой способ:

• создать самораспаковывающийся файл, который установит «путь Windows» в /opt.

• Вы можете иметь библиотеки в том же каталоге, что и исполняемый файл, но это не самый предпочтительный способ.