Здравствуйте, Unhandled_Exception, Вы писали:
UE> Скажем, я могу взять gdb, который у меня сейчас на убунте, упаковать его, и он будет условно везде запускаться?..
Типа того. Образ должен содержать весь используемый рантайм.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>У меня отладчик, который должен грузить мою *.so в отлаживаемый процесс, чтобы перехватывать функции типа malloc / free. Подозреваю, что AppImage сам перехватывает вызовы (не уверен). В принципе я уже готов отказаться от C++ в пользу обычного С, если есть гарантия, что я смогу собирать бинарники на одной машине, и это будет работать всюду (или почти всюду).
Тут обычная проблема с abi break и бинарной совместимостью с libc, libstdc++ и т.п. Тебе надо динамически юзать тот же рантайм (libc) что и приложение которое подгружает твою либу. Всё как на винде, короче. Мне кажется, тебе не надо заморачиваться и просто сделать сборку под LTS 16.04/18.хх и проверить как это всё будет работать под 18.хх. На счёт того как распространять, наверное AppImage вариант, но я его не использовал. Если платформа только убунту, то просто deb пакет сделай по правилам и в репозиторник свой засунь с подписями, gpg и т.п., но тут уже я не советчик.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>уже готов отказаться от C++ в пользу обычного С, если есть гарантия, что я смогу собирать бинарники на одной машине, и это будет работать всюду (или почти всюду).
Зачем для этого отказываться от C++? Максимум — от тех особенностей, которые недостаточно поддерживаются в линуксах. Привыкнув даже к подмножеству C++, писать на C уже очень некомфортно (если это, конечно, не C11/18 или что-то подобное).
U_E>Пользователи уговорили портировать продукт на linux. Начал разработку в убунте, дело вроде идет.
U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Я не твой коллега, в смысле не пишу шаревару под линукс (хотя участвовал в одном проекте), и предложу следующее. На десктопе используется не так много вариантов Linux, поэтому, для начала собери под тот дистрибутив, которым пользуешься сам и потребители, готовые заплатить. А дальше будешь разбираться, как сделать под другие дистрибутивы. Весьма вероятно, что кроме Ubuntu (последнего LTS) никакой другой дистрибутив поддерживать и не придется.
Приложение собирать с библиотеками (кроме libc) статически или с RPATH (как в винде с динамическими библиотеками в собственной папке, но в нее должен быть прописан RPATH относительно exe'шника). Это стандартный подход для коммерсантов, распространяющих только бинарники. Разные flatpack и другие докеры работают так: сначала тебе придется каждому пользователю объяснить, как установить flatpack на его дистрибутиве... Т.е. нифига не решат задачу, но создадут дополнительные трудности с установкой flatpack (который может быть не в каждом дистрибутиве). Ну, и как я сказал, дистрибутив может оказаться только один, либо пара и разница между ними небольшая.
K>Тут обычная проблема с abi break и бинарной совместимостью с libc, libstdc++ и т.п. Тебе надо динамически юзать тот же рантайм (libc) что и приложение которое подгружает твою либу.
Конкретно libc и libstdc++ очень хорошо поддерживают обратную совместимость. Т.е. каждая следующая версия libc будет работать с приложением, собранным с более старой версией libc. Т.е. обновление libc никак не сломает работу приложения, его даже пересобирать не нужно. Потому что в каждой последующей версии libc и libstdc++ находятся все более ранние версии функций в формате func_name@version, а при импорте указывается тоже имя с версией.
Кроме того, libc нельзя линковать статически, а libstdc++ обычно нет смысла. Единственная причина, когда у тебя что-то не сработает, если ты слинкуешь на машине с новой libc, а запускать будешь на старой libc, тогда требуемых функций с более новыми версиями не будет и приложение не запустится.
В общем, тема довольно большая, поэтому, я бы предложил ТС сначала собрать приложение на удобном ему дистрибутиве не заморачиваясь с библиотеками и их распространением, а затем тут задавать вопросы, которые появятся.
Здравствуйте, Masterspline, Вы писали:
M>Конкретно libc и libstdc++ очень хорошо поддерживают обратную совместимость. Т.е. каждая следующая версия libc будет работать с приложением, собранным с более старой версией libc. Т.е. обновление libc никак не сломает работу приложения, его даже пересобирать не нужно.
Как лучше всего настроить разработку в таком случае? Мне достаточно C++98. Начал работу в vscode, использую cmake, clang.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Как лучше всего настроить разработку в таком случае? Мне достаточно C++98. Начал работу в vscode, использую cmake, clang.
Если у тебя 10 винда Про, то скачай докер контейнер убунту или построй свой и разрабатывай поверх него не занимаясь вознёй разворачиванием виртуальных машин как минимум для компиляции и автотестов, и CI если есть. Можно напрямую в виртуалке поставить убунту и под ней всё делать. В случае, если у тебя будет новая ОС, например сентос, то ты просто возьмёшь контейнер с ней и протестишь сборку/сделаешь рпм.
M>>Конкретно libc и libstdc++ очень хорошо поддерживают обратную совместимость. Т.е. каждая следующая версия libc будет работать с приложением, собранным с более старой версией libc. Т.е. обновление libc никак не сломает работу приложения, его даже пересобирать не нужно.
U_E>Как лучше всего настроить разработку в таком случае? Мне достаточно C++98. Начал работу в vscode, использую cmake, clang.
Я же написал. Сначала определи, для какого дистрибутива твои пользователи (готовые заплатить) хотят увидеть продукт. Вот под него и разрабатывай. Дальше, если потребуется приложение под другие дистрибутивы — сообразишь, как это исправить (там будут небольшие изменения). Когда нужно будет поддерживать несколько версий одного дистрибутива (LTS последний и предыдущий), тоже посмотришь, чем они отличаются и сообразишь (возможно, достаточно будет собирать под оба дистрибутива из одних исходников, а может в новом будет новая версия какой-то библиотеки, которой нет в старой, тогда, возможно, ее придется линковать статически или через RPATH). В общем вариантов много, когда столкнешься — приходи, найдем подходящее решение.
А начинать, как я уже говорил, нужно с того дистрибутива, за который тебе готовы платить (и, возможно, никакой другой и не понадобится, либо они будут совместимы бинарно, т.е. один exe'шник будет работать на всех, либо нужно будет пересобрать из тех же исходников в каком-нибудь докере под Mint свою версию, под Ubuntu свою и то, только потому, что у них libчто-то_там различается по SONAME). Уверен, ты и сам в курсе, что на словах бывает много хотелок, а заплатить готовы три пользователя и все под Ubuntu LTS, а остальные (например, Fedora и Arch) готовы только на форумах разговоры разговаривать... Когда денег предложат — тогда и будешь реагировать на их потребности.
Здравствуйте, Masterspline, Вы писали:
M>Я же написал. Сначала определи, для какого дистрибутива твои пользователи (готовые заплатить) хотят увидеть продукт. Вот под него и разрабатывай.
Вот я и хочу понять, что означает "разрабатывать под конкретный дистрибутив"
M>новая версия какой-то библиотеки
У меня код достаточно простой: С++, системные вызовы вроде mmap. Вот вывод ld:
U_E>Вот я и хочу понять, что означает "разрабатывать под конкретный дистрибутив"
Ну, представь, что Windows — это такой очень экзотичный дистрибутив Linux. Ты же под него как-то разрабатываешь. Тут все так же. Тебе нужно либо виртуалка с Linux, чтобы там все компилировать и проверять работу. Либо тут про докер писали, но я сам под виндой не работаю, поэтому про докер с Linux'ом под винду ничего не знаю.
M>>новая версия какой-то библиотеки
U_E>У меня код достаточно простой: С++, системные вызовы вроде mmap. Вот вывод ld:
U_E>
U_E>Может так статься, что где-то не будет, скажем, libpthread.so.0?..
libpthread — это часть libc. Там ситуация такая: если ты компилируешь свое приложение под одной версией libc, то использовать можешь под той же или последующими, причем под любым дистрибутивом Linux. В теории это правило можно нарушить, но я про такое не слышал ни разу. Считай, что libc есть везде. И, как я уже писал, libc можно линковать только динамически (никакой статики). libstdc++ можно статикой, там спецключи компилятора и линковщика, но сначала полезно убедиться, что это нужно. Другие библиотеки, которых нет в дистрибутиве (или их версии различаются в разных дистрибутивах, например, OpenSSL 1.1.0 и 1.0.1), можно статикой или rpath.
Но, если ты будешь вести разработку под тем же дистрибутивом, под которым будешь распространять приложение, то эти вопросы вообще задавать нет смысла.
Вообще, тема обширная, вариантов много, поэтому вопросы лучше задавать, когда с ними столкнешься. Ну и разработку нужно вести по правилам приличия. В смысле, сборка должна делаться запуском одного скрипта (make, cmake, my_own_build_script.sh). Тогда и CI будет возможен и завернуть бинарник в deb/rpm пакет получится (или flatpack/snap/AppImage, если они тебе или твоим пользователям больше понравятся).
M>>Ну, представь, что Windows — это такой очень экзотичный дистрибутив Linux.
U_E>В нем ведь нету libc.so, не считается!
Чет какой-то жесткий offtop пошел.
Во-первых, есть. Mingw не тянет с собой libc, а линкуется с виндовыми dll (libpthread, там, возможно, нет, но большая часть libc есть). Причем, именно виндовыми, а не MSVC.
Во-вторых, речь шла про организацию разработки. Она не сильно отличается от винды (по сути, а не внешнему виду). IDE, компилятор, отладчик, документация, другие инструменты, например, виртуалка с Linux, если разработка идет под виндой, а также мозг и руки. Отличие, опять же, в мелочах, которые могут сильно отвлекать с непривычки (например, в IDE другие хоткеи или непонятно где в меню искать пути к заголовками и библиотекам в QtCreator, когда хорошо известно, где они в MSVC).
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Всем привет, U_E>Конечно, это может быть ошибкой писать именно в этот раздел, но тем не менее. U_E>Пользователи уговорили портировать продукт на linux. Начал разработку в убунте, дело вроде идет. U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть? U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники? U_E>Спасибо!
Очень просто добаляете -Xlinker '-rpath=$ORIGIN/libs' и складываете туда все so.
Или LD_LIBRARY_PATH и плюс собираете под разные архитектуры i386,x64,arm,arm64
И запихиваем в deb или rpm, на крайняк в tar.gz
Для ленивых есть конечно snap. Это тоже самое но запакованное в squashfs с блекждеком и overlayfs-ом.
Альтернатива java, но есть нюансы.
Еще можно просто в wine пускать. Или вообще кросплатформенно в dosbox
Здравствуйте, Unhandled_Exception, Вы писали:
UE> Может подкинешь ссылку на мануал, что иметь в виду, какие подводные камни?
Мануала как такового нет — просто нужно все зависимости собрать как статические библиотеки (.a) и слинковать все вместе со статической версией glibc или аналога (musl например). Основная заморочка будет со сборкой зависимостей в статические библиотеки (не всегда поддерживаются авторами в пользу динамических .so). Как только есть все .a-шки сборка своего проекта будет тривиальной.
Здравствуйте, Unhandled_Exception, Вы писали: U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Серверная часть, демон без интерфейса, у них работает действительно везде. На нашем микродистрибутиве, в котором от линукса одно ядро и кусочек libc, серверная часть запустилась сразу безо всяких костылей. Зависимости (после распаковки из upx):
$ldd vhusbdi386
not a dynamic executable
Статически линковано со всем. Привет тем, у кого "libc нельзя линковать статически".
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Несколько способов:
1) Старый добрый. Берём древнюю версию Линукса (скажем, RHEL6) и собираем на ней. На нём же собираем и нужные библиотеки зависимостей. Основные библиотеки Линукса почти идеально обратно совместимы, так что древние бинарики работают на всём более новом.
2) Альтернативно добрый. Берём Alpine Linux и собираем на нём. Он позволяет статически собрать бинарик, который ни от чего вообще не зависит. Может быть неприменимо для некоторых систем.
2.5) Можно писать на Go — там по умолчанию сразу получаются статические бинарики.
3) Модерновый. Использовать flatpak или snapcraft — они позволяют собрать контейнер, в который пакуются все зависимости. Заодно у них есть и магазины: https://snapcraft.io/store
U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники?
Лично использовал все способы.
