Можно в виде пакета в формате того дистрибутива, для которого ты хочешь свой софт распростронять. Например я некоторые свои проекты собираю пакеты в формате DEB. Я это делаю полностью через CMake. https://cmake.org/cmake/help/latest/cpack_gen/deb.html

.so - это не расширение для squid, это динамически подключаемая библиотека в Linux (аналог dll в Windows).

Cборка и распространение - два разных процесса.

Сборка - с помощью компилятора и линковщика. Но наверное тебе еще имеет смысл посмотреть на то, что такое Makefile. Это сделает тебе бинарник.

Распространение - в виде пакета соотв. дистрибутива. Там и зависимости пропишешь. Кстати, некоторые дистрибутивы отлично принимают исходники вместо бинарников.

Расширение проприетарное, нельзя код распространять?

Так сборка или распространение? Есть программа которая делает SFX архивы (обычно с расширением run), забыл, как же она называется, при распаковке может быть выполнен встроенный скрипт

В исходниках.

В общем случае - никак. Версии abi будут отличаться от дистра к дистру. Если ПО открытое - это не проблема, в противном случае проще поставлять всё месте включая проксю. Если набор дистрибутивов фиксированный, то проще всего собрать пакеты под все поддерживаемые дистры.

Да, расширениние проприетарное. Код открывать, к сожалению, нельзя

Вы имеете в виду https://makeself.io/. Вопрос именно по сборке.

Сборка в пакеты - это может быть вариант. Но где же взять зоопарк дистров для создания пакетов? То есть нужно будет держать несколько машин с разными версиями RedHat, Debian и т.д. для того, что бы не ломать ABI.

Обычно берется самый старый дистр, самой старой LTS версии. Иногда самая старая Ubuntu. Но самое надежное - текущий всё еще поддерживаемый RHEL или CentOs, самый старый из них. Проблема не так страшна, достаточно одной билд машины, и под основные дистрибутивы - просто протестировать что работает или как минимум загружается

Что за бред? Может, конечно, у squid abi ломают, но у системных библиотек типа glibc всё стабильно, иначе бы ни одна проприетарная программа не запустилась на большинстве дистров. Даже софт от microsoft типа skype нормально подхватывает системные библиотеки, при этом они не собирают пакеты для каждого дистра, а только для rpm-based и deb-based. А телеграм вообще в виде бинарника для всех дистров распространяется, и тоже системные библиотеки цепляет.

Так и делают. Можете вместо машин держать виртуалки или конейнеры.

Там у автора цэплюсплюс если что. Ну либо он теги расставляет не те. С libc тоже не всё так просто как в твоём маня мирке, но для мелких поделий с большой вероятностью не роляет и в принципе скорее экзотика. Например, если тот же openssl собрать по принципу ниже abi больше покрытие дистров, он внезапно как минимум пару дырок приобретёт, правда х3 насколько критичные они на самом деле, но в какую нить сертификацию может уже и не влезть.

Вариантов есть - это:

• докер контейнеры
• тулчейны
• да хоть бы тупо виртуалки или просто контейнеры

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

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

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 в одном образе подгрузить?

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

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

> В общем случае - никак. Версии abi будут отличаться от дистра к дистру.

Есть обратная совместимость, нет прямой совместимости. То, что было скомпилировано с Linux 4.0, libxxx 1.14.1 и libyyy 2.8.5, будет работать с Linux 5.8, libxxx 1.14.29 и libyyy 2.8.31. Наоборот - нет. Поэтому нужно компилировать программы в версиях операционной системы, хотя бы на пару релизов более старых, чем та, которой ты пользуешься.

Но даже если предположить, что автор напишет всё на 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? Будут ли программы работать быстрее?

Нет. Собрать DEB или RPM можно хоть в Gentoo. Что касается библиотек-зависимостей, то их можно ложить в пакет. Также можно собирать разными версиями компилятора тем самым обеспечив зависимость от разных версий libstdc++.

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

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

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

Да да, вот только с приложениями это работает, а с либами очень не всегда. Если у либы есть зависимости, то всё намного сложнее. Например у openssl вроде и нет abi совместимости в рамках не патч версий(а патч версия у них буковка а не правый номер в версии, т.е. 1.1.0 и 1.1.1 не совместимы, а вот 1.1.1c и 1.1.1d вполне).

Опа. А я как раз создаю билд-ферму, в которой наиболее старшая мажорная версия OpenSSL, но наиболее младшая минорная. Спасибо, выберу 1.1.1.

Для этого давно придумали mock.

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

Например у openssl вроде и нет abi совместимости в рамках не патч версий(а патч версия у них буковка а не правый номер в версии, т.е. 1.1.0 и 1.1.1 не совместимы, а вот 1.1.1c и 1.1.1d вполне)

Если это так, то это ужасно, и нарушает принципы. Что еще я не знаю об этой вселенной??? =(

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

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

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

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

Никак, распространять нужно только в исходниках. Версия openssl вот прям гарантированно не совпадёт с системной и сквид сложится с твоим блобом.

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

Это редхатовская тулза для сборки rpm в чрутах.

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

проще поставлять всё месте включая проксю

Так-так. А поподробней? Тематика C++ <> C++ и с бинарной совместимостью с плагинами собранными другими люди.

Мне лень поподробней свыше того что уже изложено в топике. Разные версии рантайма у плагина и сборочки в дистре уже могут отстрелить ногу, притом, хорошо если на уровне «не запускается». Я вот хоть убей не помню как будет выглядеть связка «хост + динамический рантайм <-> плагин + статический рантайм» под онтопиком, под виндой там вроде сразу динамик линкер по-рукам даёт, а в онтопике оно загрузится вроде даже.

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

Я когда-то пообщался с разработчиками из 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 как раз для этого, так что кто-то так делает (ставлю на гугол). Но если без извращений/хаков/патчей то понадобиися поддержка со стороны твоих зависимостей.

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