Будут ли работать статические ссылки на одном дистрибутиве Unix, но не на другом?

Question

Если я статически связываю исполняемый файл в Ubuntu, есть ли вероятность того, что этот исполняемый файл не будет работать в другом дистрибутиве, таком как mint os? или федора? Я знаю, что типы процессоров затронуты, но кроме этого, есть ли что-то еще, что я должен опасаться? Извините, если это глупый вопрос. Спасибо за любую помощь

Answer 1

Есть несколько угловых случаев, но по большей части вы должны быть в хорошей форме со статическим связыванием. На ум приходит libnss. Эту конкретную библиотеку по существу невозможно статически связать из-за того, как она выполняет свою работу (разрешения, аутентификация, задачи безопасности). Пока glibc-версии похожи, вы должны быть в порядке в этом вопросе.

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

Большинство типичных приложений, которые даже имеют смысл обсуждать переносимость, такие как сетевые сервисы, графические приложения, языковые инструменты (например, компиляторы / интерпретаторы), не будут иметь проблем с этим.

Answer 2

Если вы статически связываете программу на одном компьютере, а затем перемещаете ее на другой компьютер, на котором система в основном работает аналогичным образом, тогда она должна работать нормально. В этом смысл статического связывания; что нет никаких других файлов, от которых зависит программа - она ​​полностью автономна, поэтому, пока она вообще может работать, она будет работать так же, как и в своей "главной" системе.

Это отличается от динамического связывания, при котором программа включает элементы других файлов (библиотек) во время выполнения. Если вы переместите динамически связанную программу в другую систему, где библиотеки, от которых она зависит, отличаются (или не существуют), она не будет работать.

Answer 3

В большинстве случаев ваш исполняемый файл будет работать нормально. Пока ваш исполняемый файл не зависит от наличия чего-либо необычного для его работы, проблем не будет. (И, если это зависит от присутствия чего-то необычного, у вас возникнет та же проблема, даже если вы динамически создадите ссылку.)

Статическое связывание обычно безопаснее, чем динамическое связывание, для совместимости между различными средами UNIX, если используется один и тот же ЦП.

Чтобы иметь статически связанный двоичный сбой, опять-таки, предполагая, что архитектура процессора такая же, вам нужно сделать что-то, например, ссылку в системе, использующую двоичный формат a.out, и попытаться выполнить ее в системе, в которой работает ELF, в которой В случае, если динамически связанная версия потерпит неудачу так же плохо.

Так почему же люди не регулярно связывают статически? Две причины:

• Это делает исполняемый файл больше, иногда НАМНОГО больше, и
• Если ошибки в библиотеках исправлены, вам придется повторно связать свою программу, чтобы получить доступ к исправлениям ошибок. Если в библиотеках исправлена ​​критическая ошибка безопасности, вы должны заново связать и распространить ваш exe.

Answer 4

Здесь обсуждаются два вопроса совместимости: версии библиотеки и инвентарь библиотеки.

Вы не говорите, какие библиотеки используете.

Если у вас нет опций -l, единственной библиотекой является сам glibc, который служит интерфейсом для ядра. Версии Glibc совместимы вверх. Если вы ссылаетесь на систему glibc 2.x, вы можете запустить ее на glibc 2.y, если y> x. Разработчики твердо привержены этому.

Если у вас есть параметры -l, статическое связывание всегда безопасно. Если вы динамически связаны, вы должны убедиться, что (1) библиотека присутствует в целевой системе и (2) имеет совместимую версию. Ваш пробег может зависеть от того, есть ли у целевого дистрибутива то, что вам нужно.

Answer 5

Нет, это не будет работать. Статическое связывание для независимости от дистрибутива является понятием из старых эпох Unix и не рекомендуется. К тому же, вы не можете использовать столько библиотек, сколько статических библиотек.

Следуйте стандартному стандарту Linux, это ваш единственный шанс получить как можно больше кросс-дистрибутивной переносимости.

LSB также отлично работает, если вы программируете для FreeBSD и Solaris.

Answer 6

Пока вы можете гарантировать, что она будет выполняться только в аналогичной версии ОС на аналогичном оборудовании, ваша программа будет работать нормально, если она статически связана. поэтому, если вы соберете Linux 2.6 и статически подключитесь, вы сможете работать (почти) во всех дистрибутивах Linux 2.6.

Имейте в виду, что вы не можете статически связывать некоторые части GLIBC, поэтому, если вы используете их, вам все равно придется динамически связывать. Из памяти части службы имен (nss) требовали динамического связывания, когда я его исследовал.

Вы не можете статически связать программу для (скажем) Linux, тогда ожидайте, что она будет работать на BSD или Windows. BSD и Unix не представляют и не обрабатывают свои системные вызовы так же, как Linux. Я говорю неправду, потому что в BSD есть слой эмуляции Linux, который можно включить, но из коробки он не будет работать.

Answer 7

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

Это, как говорится, должно работать на любом другом подобном ядре с той же архитектурой (то есть, если вы статически подключаетесь на машине под управлением Linux 2.4.x, загрузчик VDSO будет отличаться на Linux 2.6, VDSO будет виртуальной динамической общий объект, общий объект, который ядро ​​предоставляет каждому процессу, содержащему код загрузчика).

К другим подводным камням относятся вещи, которые в / etc находятся не там, где вы думаете, журналы находятся в разных местах, системные утилиты отсутствуют или отличаются (ubuntu использует update-rc.d, RHEL использует chkconfig) и т. Д.

Иногда у тебя просто нет выбора. Я писал программу, которая говорила со строковым интерфейсом cmdlib в LVM2 в пользу использования execv () ... low, и вот, 30% дистрибутивов, которые мне нужно было поддерживать, НЕ включали эту библиотеку и не предлагали ее получить. Поэтому при создании бинарных пакетов мне пришлось ссылаться на статический объект.

Если вы используете glibc, вы можете быть уверены, что такие вещи, как getpwnam () и друзья по-прежнему будут работать ... просто следите за любыми жестко заданными путями (еще лучше, сделайте их настраиваемыми во время выполнения)

Answer 8

наоборот. Какими бы ни были ваши шансы получить двоичный файл для работы с дистрибутивами или даже операционными системами, эти шансы максимизируются статическими ссылками. Статическое связывание делает исполняемый файл автономным с точки зрения библиотек. Он все равно может пойти не так, если попытается прочитать файл, которого нет в другой системе.

Чтобы повысить шансы на переносимость, попробуйте установить связь с dietlibc или другим libc. В статье в Linux Journal упоминаются некоторые кандидаты. Меньший, более простой libc менее вероятно будет зависеть от вещей в файловой системе, которые отличаются от дистрибутива к дистрибутиву.