Статическая связь Linux мертва?

Ответ 1

Относительно этого факта существует ли разумный способ создания полностью действующей статической сборки на Linux или статической связи полностью лишен Linux?

Я не знаю, где найти исторические ссылки, но да, статическая ссылка мертва для систем GNU. (Я считаю, что он умер во время перехода от libc4/libc5 к libc6/glibc 2.x.)

Эта функция считалась бесполезной в свете:

• Уязвимости системы безопасности. Приложение, статически связанное, даже не поддерживает обновление libc. Если приложение было связано с системой, содержащей уязвимость lib, она будет сохранена в статически связанном исполняемом файле.

• Накидка кода. Если в одной системе запущено много статически связанных приложений, стандартные библиотеки не будут использоваться повторно, поскольку каждое приложение содержит внутри своей копии все. (Попробуйте du -sh /usr/lib, чтобы понять степень проблемы.)

Попробуйте скопировать архивы списков LKML и glibc-mail с 10-15 лет назад. Я довольно уверен, что давно видел что-то связанное с LKML.

Ответ 2

Я думаю, что это очень раздражает, и я считаю, что самонадеянно назвать функцию "бесполезной", потому что она имеет проблемы с определенными вариантами использования. Самая большая проблема с подходом glibc заключается в том, что он жестко кодирует пути к системным библиотекам (gconv, а также nss), и, таким образом, он ломается, когда люди пытаются запустить статический двоичный файл в дистрибутиве Linux, отличном от того, для которого он был создан.

Во всяком случае, вы можете обойти проблему gconv, установив GCONV_PATH, чтобы указать на соответствующее местоположение, это позволило мне взять исполняемые файлы, созданные на Ubuntu, и запустить их в Red Hat.

Ответ 3

Статическое соединение не похоже на любовь в мире Linux. Вот мой прием.

Люди, которые не видят привлекательности статической привязки, обычно работают в области ядра и операционной системы нижнего уровня. Многие разработчики библиотеки nix потратили целую жизнь на решение неизбежных проблем, связанных с попыткой связать сотню постоянно меняющихся библиотек, задача, которую они выполняют каждый день. Взгляните на autotools, если вы когда-либо захотите узнать, какие backflips им удобнее выполнять.

Но все остальные не должны тратить большую часть времени на это. Статическая привязка займет у вас долгий путь к буферизации от сбоя библиотеки. Разработчик может обновить свои программные зависимости в соответствии с графиком программного обеспечения, а не быть вынужденным делать это в тот момент, когда появятся новые версии библиотеки. Это важно для приложений, ориентированных на пользователей, со сложными пользовательскими интерфейсами, которым необходимо управлять потоком многих библиотек более низкого уровня, от которых они неизбежно зависят. И поэтому я всегда буду поклонником статической связи. Если вы можете статически связывать скомпилированный переносимый C и С++ код, вы в значительной степени сделали мир своей устрицей, так как вы можете быстрее поставлять сложное программное обеспечение в самые разнообразные мировые постоянно растущие устройства.

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

Ответ 4

Просто потому, что вы должны динамически ссылаться на службу NSS, не означает, что вы не можете статически ссылаться на какую-либо другую библиотеку. Все эти часто задаваемые вопросы говорят о том, что даже "статически" связанные программы имеют некоторые динамически связанные библиотеки. Это не говорит о том, что статическая привязка "невозможна" или что она "не работает".

Ответ 5

Добавление других ответов:

Из-за причин, сказанных в других ответах, это не рекомендуется для большинства дистрибутивов Linux, но на самом деле существуют дистрибутивы, созданные специально для запуска статически связанных двоичных файлов:

• stali
• morpheus
• starchlinux
• bifrost

Из описания stali:

static linux основан на выбранной вручную подборке лучших инструментов для каждой задачи, и каждый инструмент статически связан (включая некоторые X клиенты, такие как st, surf, dwm, dmenu),

Он также нацелен на уменьшение двоичного размера за счет избежания glibc и другие раздутые библиотеки GNU, где это возможно (ранние эксперименты показывают что статически связанные двоичные файлы обычно меньше, чем их динамически связанные glibc-коллеги!!!). Заметьте, это в значительной степени вопреки тому, что Ульрих Дреппер считает статической связью.

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

Статическая привязка также помогает уменьшить зависимость.

Вы можете прочитать об этом в этом вопросе о статической и динамической компоновке.

Ответ 6

Статическое связывание снова на подъеме!

• Многие (большинство?) Исполняемые файлы языка программирования Go статически связаны.
  • Повышенная мобильность и обратная совместимость - одна из причин их популярности.
• Другие языки программирования прилагают аналогичные усилия, чтобы сделать статическое связывание действительно простым, например, Haskell (я работаю над этим усилием).
• Настраиваемые дистрибутивы/наборы пакетов Linux, такие как NixOS/nixpkgs, позволяют статически связывать большую часть их пакетов (например, его pkgsStatic пакетов pkgsStatic может предоставлять все виды статически связанных исполняемых файлов).
• Статическое связывание может привести к лучшему устранению неиспользуемого кода во время соединения, уменьшая размер исполняемых файлов.
• libcs, такие как musl, делают статическое связывание простым и корректным.
• Некоторые крупные лидеры индустрии программного обеспечения согласны с этим. Например, Google пишет новую библиотеку libc, нацеленную на статическое связывание ("поддержка статического связывания без PIE и статического связывания с PIE", "мы не намерены инвестировать в этот момент [в] поддержку динамической загрузки и связывания").