LINUX.ORG.RU
Форум — Development  

Где делать универсальную сборку

 ,


1

1

Привет, ЛОР.

Приходилось сталкиваться с мнением, что наилучший способ получить универсальный бинарник под линуксом — это собирать проект под в меру стареньким дистрибутивом и соответственно, со стареньким glibc.

Какой дистрибутив для этого лучше взять в 2023 году? Debian Oldstable (который сейчас Buster) подойдёт?

★★★★★
← Сгенерировать список файлов для каждого коммита
Мейкфайл умеет в опции в виде -opt? →
 ← 1 2

Приходилось сталкиваться с мнением

Такое себе, распространять софт универсальным бинарником. Как пользователь говорю, часто сталкиваюсь, что авторы-сборщики любят мудрить с флагами, поддержкой уникальных фич процессора и т.п.

И не смотря на наличие бинарника всё-равно приходится собирать из исходников самому.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)

ЕМНИП glibc ты всё равно в сборку засунуть не сможешь, потому что в системе не может быть двух glibc одновременно, что то там ломается (я не настоящий сварщик). Поэтому собсно и во флатпаках glibc нет и быть не может. Смысл рекомендации собирать в системе со старым glibc — в обратной совместимости. Собранное там заработает и в новых системах, со свежим glibc, а вот наоборот — уже не факт.

Я бы рекомендовал всё же на flatpack и его эталонное окружение ориентрироваться, там хотя бы уже устаканившиееся окружение есть. И наверняка рекомендованная для сборки версия системной glibc тоже как то озвучена.

Jameson ★★★★★
()

Собирай на wheezy, не ошибёшься. А так - всё зависит от того, насколько древняя совместимость тебе нужна. Buster всё-таки довольно новый релиз, ему меньше 5 лет. Я бы как минимум stretch использовал.

firkax ★★★★★
()

Использовал 2 варианта:

  • doсker-контейнер manylninux2014 (основан на Centos7)
  • использование в качестве С/С++ компилятора Clang-обёртки zig cc. Она по сути выполняет кросс-компиляцию с динамическим заданием целевой платформы. В том числе можно указывать версию glibc на какую линковаться. Что-то типа -target x86_64-linux-gnu.2.17. Я этот вариант забросил, так как он почему-то в отличие от cross-mingw под rhel7 не смог под винду сkинковать проект. Сам язык zig пр этом использовать/знать совершенно не требуется, это просто кросскомпилятор с динамическим заданием таргета. https://zig.news/kristoff/cross-compile-a-c-c-project-with-zig-3599
GPFault ★★
()
Ответ на: комментарий от Jameson

Как раз таки flatpak тащит с собой полное окружение вместе с glibc. Сейчас там окружение похоже на последнюю Ubuntu LTS. Смысл flatpak’а - предоставить стандартизированное (какое там уже по счету) окружение, под которое разработчики могут собирать софт.

Отсюда вывод, что лучший универсальный бинарник - архив с исходниками.

undef ★★★
()

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

Типа такого: «мы компилируемся с gtk 3.10, но часть фич работать не будет; чтобы работали все, нужна сборка с gtk 3.20».

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

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)

Если с целью, озвученную раньше в другом топике (демонстрировать новую версию DoubleContact тем, не умеет собрать) - AppImage. Если планируется в дальнейшем разпространять новые версии, то Flatpak.

Ещё можно разместить в опензузешным OBS, там довольно легко собирать пакеты для многих дистров одновременно.

token_polyak ★★★★★
()
Последнее исправление: token_polyak (всего исправлений: 3)
Ответ на: комментарий от dataman

Qt я для такого случая соберу статически (по крайней мере, под виндой я это делал, думаю, и под линуксом сделаю). Интересует вопрос с более «базовыми» библиотеками.

hobbit ★★★★★
() автор топика

Мысли в слух

oldoldstable был актуелен ~6 лет назад. Думаю самое то. Три года назад всего последнее обновление было для Debian 9 («stretch»).

Текущее время минус три релиза назад включая текущий. ИМХО золотая середина. И достаточно устоявшееся и не шибко то и старое. Более свежее брать разве что ради пофикшенных CVS каких наверное, а более раннюю версию, ну тут может уже текущий софт то не соберётся с компонентной базой старой ибо опирается на функции которых тогда тупо не было. Тутава надо пробовать.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от Jameson

Поэтому собсно и во флатпаках glibc нет и быть не может.

Это не так.

ТС: Контейнеры – каноническое решение на сегодняшний день. Flatpak, возможно, не лучший вариант. Докеры/подманы могут быть удобнее за счет стандартизации, позволяют заменить все, кроме кернела.

i586 ★★★★★
()

присоединяюсь к совету про zig cc. Эта штука не только позволяет скомпилять проект под любую версию glibc, но еще и полностью портабельна. Докеры, флатпаки и прочая фигня просто не нужны.

Lrrr ★★★★★
()
Ответ на: комментарий от alex1101

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Например, вот так. 

root@52419001a30a:/usr/src/teledroid# ./teledroid 
./teledroid: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./teledroid)
./teledroid: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./teledroid)

Контейнер на базе stable debian libc 2.31-13, а бинарник собран под Gentoo, где sys-libs/glibc (2.36-r8). Буквально сегодня столкнулся, когда pipeline для сборки одного велосипеда у себя перетаскивал из gitea+droid на gita actions.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Но тут требуется более новая версия glibc, потому что в старой glibc не было символов с нужными версиями. Разве в новых версиях удаляли какие-то старые версии символов?

i-rinat ★★★★★
()

Я ориентируюсь на стабильный Debian или Ubuntu LTS обычно. Когда Debian становится oldstable, я ещё примерно полгода-год, остаюсь на нём и только потом начинаю переезжать на актуальный stable.

shell-script ★★★★★
()
Ответ на: комментарий от alex1101

В сообщении под твоим есть пример, как запускатор ругается, когда символов не находит. Но это бывает, когда glibc слишком старая. По идее, такого не должно быть, когда glibc достаточно новая, потому что они тянут старые версии кода с «особенностями» для совместимости.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

А, прости. Я запутался в ответах этой ветки. Разумеется, я имел ввиду ошибку, когда под старым libc на запускаются собранные с новым. Наоборот я тоже не видел.

shell-script ★★★★★
()
Ответ на: комментарий от i-rinat

Не, точно не такой случай, на такой я бы даже внимания не обратил, понятно же, что собранное с новым glibc может не работать со старым. А вот в обратную сторону привлекло моё внимание.

alex1101 ☆
()
Последнее исправление: alex1101 (всего исправлений: 1)

Нигде, собирай максимально статики и со статической libc. Для изучения вопроса глубже, рекомендую почитать книжку Милана Стевановича «Advanced C and C++ Compiling», там прям очень подробно про компиляцию и различные тонкости, типо переносимости символов путём их версионирования и пр. В целом вне статика переносимость ближе всего к понятию стабильности и соответственно чем стабильнее дистр берёшь, тем лучше должно получиться, но… практика говорит, что это круто, но не панацея и гарантий не даёт. Также если читать нет времени/желания, то ещё можно посмотреть ролик разраба из кликхауса с C++ Россия.

Кстати идея взять AppImage хорошая, но тут нужно запариться с двумя вещами - носить нестабильные библиотеки с собой, статически связать libc и хорошенько потестить по вопросу разрешений и ограничений библиотек и хранилища squashfs

AKonia ★★★
()
Последнее исправление: AKonia (всего исправлений: 1)

Нетрудно догадаться, что это зависит от целевых систем и аудитории. «Универсальные» бинарники делают, как правило, для двух случаев: 1) для распространения проприетарщины; 2) для удобства части пользователей, которым в противном случае пришлось бы компилять сорсы. В обоих случаях нужно хотя бы примерно понимать, кто ваши пользователи и на каких дистрибутивах они, в основном, сидят - у «арчешкольники» с bleeding edge и HPC’шников с системами десятилетней давности потребности будут разными.

В былые времена хорошим тоном считалось взять самый старый, но еще поддерживаемый RHEL (в виде CentOS).

annulen ★★★★★
()

мы собираем под ubuntu 18.04
Это самый древний из живых линуксов и всё собранное под ним, работает и на свежих.

Очень геморроен libstdc++, его для переносимости надо таскать с собой, особенно для центоса, в котором полный бардак и сборка в докере под centos не гарантирует, что оно запустится на той же версии у клиента: версии библиотек и конфликтующие символы в них спонтанно меняются.

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

Очень геморроен libstdc++, его для переносимости надо таскать с собой

Да, но есть неприятный нюанс: если подгружать libstdc++ через LD_LIBRARY_PATH, могут возникнуть проблемы с вызовом из приложения внешних процессов. Нужно фильтровать при таких вызовах переменные среды или использовать линковку с $ORIGIN вместо LD_LIBRARY_PATH

annulen ★★★★★
()
Ответ на: комментарий от annulen

совершенно верно.

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

В этом шеллскрипте подсовываются все нужные либы.

max_lapshin ★★★★★
()
 ← 1 2
← Сгенерировать список файлов для каждого коммита
Development
Мейкфайл умеет в опции в виде -opt? →