ошибка статической компоновки

libc должна быть

Не хватает статической версии libc. Почему ее нет в стандартном пакете? Собирательно это можно выразить так: линкуясь со статической libc, огребаешь много проблем. Подробнее — в Гугл с запросом «linking with static glibc».

а можешь в двух словах разъяснить? а то я что-то погуглил «linking with static glibc» ничего особенно страшного не нашёл.

а можешь в двух словах разъяснить? а то я что-то погуглил «linking with static glibc» ничего особенно страшного не нашёл.

Я тоже не нагуглил с ходу ничего страшного. Изложу из головы, как понимаю сам. Статическая компоновка по ряду причин признана сообществом неподходящей, поскольку: а) увеличивает размер исполняемых файлов, в результате чего система пухнет; б) понижает стабильность системы, поскольку если мы хотим закрыть уязвимость в библиотеке libx, то при динамической компоновке необходимо лишь обновить сам файл библиотеки, при статической же компоновке софт сохранит эту уязвимость до тех пор, пока не будет пересобран с новой версией библиотеки.

В результате уже довольно много библиотек, в т.ч. системных, спроектированы так, что будут хреново функционировать, будучи скомпонованы статически. Яркие примеры — библиотеки NSS.

Первая NSS — Name Service Switch, компонент libc. В документации явно прописано, что не стоит пытаться использовать NSS и libc в статическом режиме, не взлетит.

Вторая NSS — криптографическая библиотека, которую использует проект Mozilla. В нее входит компонент NSPR, Netscape Portable Runtime, благодаря которому проект настолько кроссплатформенный, как сейчас. В недрах этого рантайма есть несколько глобальных мьютексов. Компонуя динамически, мы обеспечиваем единственность этих мьютексов, а в статике у нас может быть создано несколько не синхронизированных между собой копий, и все взорвется. Об этом тоже написано в документации.

спасибо за развёрнутый ответ.

по поводу описанной ситуации с nspr. допустим у меня есть две программы, одной нужна новая версия, а в другой предыдущая. получается, что я не могу их запустить одновременно? иначе «всё взорвётся». зачем вообще выбирать такой дизайн системной библиотеки? зачем делать такой мутекс? с целью оптимизации? хреновая оптимизация на мой взгляд, т.к. она не покрывает всех возможностей «не оптимизированной» версии.

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

Статическая компоновка по ряду причин признана сообществом неподходящей, поскольку: а) увеличивает размер исполняемых файлов, в результате чего система пухнет;

Это да. Но сегодня это уже не играет такой роли как когда-то дааавно.

б) понижает стабильность системы, поскольку если мы хотим закрыть уязвимость в библиотеке libx

А вот тут другое сообщество (plan 9 / golang) говорит обратное. Прога работала стабильно, тут обновили одну либу, от которой зависит и 100 других прог, чтобы они работали лучше, а та одна прога теперь сбоит. Вот тебе и стабильность.

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

Ну, в Солярке статику выкинули вообще, потому что там функции для многопоточным приложений переместили в libc (из libpthread and libthread), и следовательно инициализация многопоточных приложений стала невозможной [без костылей] при статической линковке.

А по теме, ищи пакет типа libc-static. В Дебиане статические библиотеки находятся в пакетах *-dev.

по поводу описанной ситуации с nspr. допустим у меня есть две программы, одной нужна новая версия, а в другой предыдущая. получается, что я не могу их запустить одновременно?

man backward_compatibility

man soname

man symbol_versions