Там у автора цэплюсплюс если что.

А что не так с С++?

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Тут пишут что с gcc 3.4 версия libstdc++.so стала 6.0.0 и пока больше не менялась. GNU в маразме и забывает менять версии при смене ABI?

Опять же, как работают С++ программы собранные на Centos 5 на современных дистрах, если ABI сменилось?

Не, если не использовать 11ый стандарт и выше, то так-то можно попасть во всё что в проде(ну почти, есть ультрастабильные ребяты которые сидят даже на неподерживаемых версиях, и что самое обидное у них зачастую больше всего денех…). А так да версию не меняют, а вот версии символов меняют. Про мотивацию х3, честно даже не задавался этим вопросом, пока ты внимание не обратил.

А не, гоню версию же тоже меняют только патч компонент.

Но даже если предположить, что автор напишет всё на 03ем стандарте, выставит в флагах минимальную версию плюсового abi под свой стандарт(это например прокатывало с полной поддержкой 11ого стандарта но под дефолтный рантайм centos6, где был gcc4.8 только с урезанной версией) - какую версию openssl ему выбрать что бы и под 9ый и под 10ый дебиан работало? 1.1.0? А чего будет если две версии openssl в одном образе подгрузить?

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

Но даже если предположить, что автор напишет всё на 03ем стандарте, выставит в флагах минимальную версию плюсового abi под свой стандарт(это например прокатывало с полной поддержкой 11ого стандарта но под дефолтный рантайм centos6, где был gcc4.8 только с урезанной версией) - какую версию openssl ему выбрать что бы и под 9ый и под 10ый дебиан работало? 1.1.0? А чего будет если две версии openssl в одном образе подгрузить?

Я не имею понятия как это делается для плагинов, но для приложений можно просто все so библиотеки положить в папку libs рядом с бинарником, при сборке приложения указать rpath и dynamic-linker И всё будет работать примерно как в Windows, никакие системные библиотеки использоваться не будут, только свои.

Я сам собираю на rolling Manjaro, и потом тестирую что запускается на Ubuntu 12.

Единственный минус, это размер приложения. glibc + libstdc++ ~24 мегабайта занимают, + размер всех остальных используемых библиотек.

Остаются лишь требования glibc к версии ядра Linux. Сейчас вроде у последней glibc - 3.2 минимальная версия…

Есть ли смысл использовать более новые Glibc? Будут ли программы работать быстрее?

Есть ли смысл использовать более новые Glibc? Будут ли программы работать быстрее?

Вряд ли. Ну то есть когда новые версии выходят, там обычно есть ускорение в определенных функциях, но я не думаю что это ускорит случайную программу.

Я так и подумал, что большинство высказавшихся за понижение abi масштабируют свой подход с прилжоением. С либами это плохо работает вот почему - прямое назначение либы загружаться в приложение со своим набором зависимостей на который ты не можешь влиять(ну как, ты можешь и само приложение поставлять). Можно провести эксперимент очень простой - взять даже одной версии статический рантайм и загрузиться в приложение использующее динамический. Не факт, что эффект станет заметен сразу, но это точно аукнется.

БольнойУблюдок.жпг

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

Я тебе больше скажу - можно завернуть в неймспейс и вызовы разных версий других либ на уровне линковщика. Только это уже не самый простой и стандартный способ и х3 какие там грабли придётся собирать:)

Так если собрать всё статически, то разве нельзя скрыть все символы кроме нескольких (-fvisibility=hidden+аттрибуты или может через -Wl,--version-script)? С C-API тут проблем быть не должно, а он, наверное, и используется.

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

В теории звучит как план если abi сишный. Пока сходу не могу представить где выйдет подстава.

Я когда-то пообщался с разработчиками из Unigine, сказал что в какой-то их проге требуется слишком уж новый Glibc. Спустя пару лет, когда вышел Unigine Superposition, я сделал strings superposition | grep LIB и увидел, что теперь наоборот, требуется неприлично малая версия этой библиотеки. Как они это сделали, я не знаю, но подозреваю, что они собирают в новой системе, заставив компилятор не использовать новые вызовы Glibc.

Ну а я бинарники для личного пользования компиляю в CentOS 6, Debian 6 и SLES 11.

Ещё да, придётся тулчейн собрать с самой низкой версией сишного abi на которой стандарт нужный заработает(но это вроде почти любой, под 5ый и вроде даже под 4ый rhel точно можно с 17ым заходить в такой конфигурации).

Кстати да, можно, +1. У LLVM рантаймов есть опции HERMETIC_STATIC_LIBRARY как раз для этого, так что кто-то так делает (ставлю на гугол). Но если без извращений/хаков/патчей то понадобиися поддержка со стороны твоих зависимостей.

// В целом не экспортировать символы из статики это нормальная практика, так что много проблем быть не должно, но что-нибудь наверняка выстрелит