Статические проблемы блокируют динамическое бытие. Что можно популярного почитать про проблемы статической линковки в современном Линуксе?

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

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

Почитай https://t.me/itpgchannel - это канал чувака из Яндекса, который пилит свой полностью статический дистрибутив. Можешь ему и вопросы позадавать. У него там много интересного секса в гамаке начиния с сборок того что статически собираться не обучено и заканчивая статической линковкой того что обязано быть динамическим, как-то подгружаемые плагины и динамический диспач между реализациями opengl.

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

Нет такого. Есть логика завязанная на загрузку библиотек в рантайме (dlopen) типа упомянутых плагинов, которая по понятным причинам для статической линковки требует полного {вы,пере}пиливания, а в общем любой код всегда можно прилинковать как угодно.

Мне кажется что-то из базового, типа libstdc++/libc

Это обязано уметь линковаться статически, иначе какой будет смысл линковать статически что-то ещё?

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

Depends. На старых ядрах могут не поддерживаться какие-то интерфейсы которые нужны libc с которой ты собрался, бывают зависимости на внешние файлы - условно другой формат базы данных таймзон = и у тебя не работают даты. Если у тебя практическая задача, а не мастурбация, то зачем тебе статическая линковка? Собирайся нормально, распространяйся исходниками.

Собирайся нормально, распространяйся исходниками.

Я использую некоторые библиотеки (libconfig, монcтро-ICU), которых у пользователя, скорее всего, нет. Идея была наиболее стрёмные либы слинковать статически.
Вопросы о тотальной статике пришли как аппетит во время еды.

Я использую некоторые библиотеки

«Некоторые» линковать статически нельзя ни в коем случае. С другой библиотекой притащится другая версия и всё накроется. Либо всё либо ничего.

(libconfig, монcтро-ICU) которых у пользователя, скорее всего, нет

ICU конечно же у всех есть, от неё зависят и ff и хром и либра и boost. И её линковать статически нельзя потому что у неё есть файл с данными, формат которого несовместим между версиями. Во-первых, не понятно как ты её собрался использовать без данных, во-вторых, если в системе окажутся данные от другой версии всё опять же накроется.

Много весит как раз этот файл, сама же библиотека очень лёгкая. Если ты притащищь файл, «монстро-» уже будет твоя поделка, а так как ты притащишь файл второй раз в дополнение к системному, она будет ещё и «говно-».

Звучит логично, спасибо за совет.

у ядра нет такого уж стабильного интерфейса

Системные вызовы ядра меняются от версии к версии.

Ты случаем ЛОР с винфаком не перепутал?

А обязательно поставлять одним бинарником? Можно же библиотеки вместе с ним укомплектовать, указав rpath, няпример.

https://www.akkadia.org/drepper/no_static_linking.html, в частности """ all kinds of features in the libc (locale (through iconv), NSS, IDN, …) require dynamic linking to load the appropriate external code. We have very limited support for doing this in statically linked code. But it requires that the dynamically loaded modules available at runtime must come from the same glibc version as the code linked into the application. And it is completely unsupported to dynamically load DSOs this way which are not part of glibc. Shipping all the dependencies goes completely against the «advantage» of static linking people cite: that shipping one binary is enough to make it work everywhere. """

Вызовы типа iconv(), getpwent(), getaddrinfo() всегда динамически грузят библиотеки. glibc не имеет механизма статически слинковать их в один бинарник.

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

Например в библиотеках может использоваться dlopen/dlsym, который не работает при статической линковке.

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

Нет:

1. Формат ELF используется не только в Линуксе.

2. Программы могут требовать определённое окружение и сервисы для работы, например определённые драйверы ядра, X.Org, Wayland, D-Bus сервисы и т.д..

Ты случаем ЛОР с винфаком не перепутал?

Прямо в самой первой и самой последней версии ядра ничего не поменяли?

Насчёт самой первой не знаю, но в Linux с древних времён свято блюдётся обратная совместимость для «юзерспейса». А вот в Windows номера системных вызовов могут меняться, например, из-за чего их дёргают через WinAPI-обёртки.

Системные вызовы ядра меняются от версии к версии.

o_O

Это какие например? Ты что-то куришь?