Линковка к символическим ссылкам

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

Игра свободная? Тогда не надо распространять её бинарники вообще. Ни тратить время на это, ни порождать неработающее говно в итоге. Можете почитать по теме. Главное, нормальную систему сборки сделайте.

Если игра несвободная, валите в Job, или ту выгребную яму где ваша проприетарная братия тусуется и там спрашивайте.

Игра свободная.
Кто хочет собрать вручную - пусть собирает, но мне нужно, чтоб её играли не только красноглазики вроде меня, а и люди, которые не разбираются в компьютерах.
Да и зачем каждому тратить время на сборку, если можно потратить это время только один раз и поделиться результатом.
Собираю не у себя, а на CI, и там можно глянуть хеш суммы, для тех кто боится троянов.

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

Мне кажется на систему сборки и CI я потратила даже больше времени чем на саму игру.

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

Делай appimage тогда, охват будет больше.

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

Почитай статью. Чтобы не-красноглазики её не собирали, её опакетят в родных репозиториях. А вот с криво собранными бинарниками они намучаются, факт - осознай что в принципе нельзя сделать бинарник зависимый от библиотек в дистрибутивах, которые могут быть и будут бинарно несовместимы. А в первом посте ты ещё и спрашиваешь как отключить защиту от этого.

Собираю не у себя, а на CI, и там можно глянуть хеш суммы, для тех кто боится троянов.

Почему вы думаете что можно доверять CI? Запихнуть троян в CI - раз плюнуть.

Она работает и на винде, и в будущем также добавлю поддержку макоси.

Чтобы не-красноглазики её не собирали, её опакетят в родных репозиториях.

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

которые могут быть и будут бинарно несовместимы

Я встречала несовместимость ABI, она бывает не так уж и часто. Можно протестировать на многих дистрах и исправить проблемы с совместимостью.

Почему вы думаете что можно доверять CI? Запихнуть троян в CI - раз плюнуть.

CI показывает, с какого коммита он собрал, ну и скрипты сборки все лежат в гите вместе с проектом. Я не думаю что там просто найти уязвимость, которая позволит подсунуть троян. И да - кто всё равно боится трояна, может собрать сам.

бывает не так уж и часто

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

Если хочешь, чтобы играли не-красноглазики, то собери несколько пакетов для не-красноглазых дистров. Там скажем deb для ububtu 18.04 и 20.04, rpm для федоры.

Мне бы хотелось чтоб можно было просто установить зависимости, разархивировать архив с моей игрой и играть

-Wl,-rpath=. и пачку сошек рядом с бинарником, problem soved

На самом деле нет, start.sh с LD_LIBRARY_PATH всё равно нужен

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

А если ты про симлинки, то это костыль.

На самом деле нет, start.sh с LD_LIBRARY_PATH всё равно нужен

Почто?

Если сошки будут вместе с игрой то нет никакого смысла в динамической линковке

лучше тогда использовать статическую

man лицензия

И вот еще чтиво, чтобы понимать, откуда у .so.1 растут ноги: https://github.com/asheplyakov/dsoabivers

Может после этого станет чуточку понятнее, что ты хочешь какой-то дичи.

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

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

Я встречала несовместимость ABI, она бывает не так уж и часто. Можно протестировать на многих дистрах и исправить проблемы с совместимостью.

Их нельзя исправить. Есть ABI с которым был скомпилирован код, есть ABI у библиотеки на целевой машине. Если эти ABI не совпадают, всё сломано. Если на целевых машинах встречаются разные (версии) ABI, то ваш бинарник гарантированно сломан на части из них, потому что собраться вы можете только с одной конкретной. Более того, даже если сейчас всё везде работает, то завтра сломается потому что кто-то изменит ABI. Родные пакеты просто пересоберут, а ваш блоб пойдёт лесом.

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

CI не предназначен для безопасных сборок, и уязвимости тут не при чём (хотя конечно это тоже фактор, ибо чем больше таких как вы собирают в CI бинарники тем более он лакомая цель, а дыры находят во всём подряд десятками в неделю). Travis полностью контролирует сборочное окружение и может подложить вам в бинарник что угодно даже не особо маскируясь, а вы ничего не заметите. Вы сами можете манипулировать кэшом или установленными пакетами чтобы незаметно подложить в бинарник что угодно чего нет в коде. Да господи, глядя на ваши переусложнённые CI скрипты вынесенные аж в отдельную директорию, могу сказать что вы прямо в них можете сделать что угодно и никто не заметит. На будущее: сложность CI скриптов отражает сложность вашей сборки. Поэтому в хорошем проекте там не должно быть ничего кроме установки зависимостей и cmake –build –install.

И да - кто всё равно боится трояна, может собрать сам.

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

man лицензия

Хм, не думала, изучу вопрос. Вроде как позволительные лицензии, мне казалось что должны позволять.

Их нельзя исправить. Есть ABI с которым был скомпилирован код, есть ABI у библиотеки на целевой машине. Если эти ABI не совпадают, всё сломано.

Ну, например несовместимость с libconfig собранным на другой версии компилятора можно исправить либо собрав проект тем же компилятором, либо отказаться от него в пользу libjsoncpp, как сделала я.

Да господи, глядя на ваши переусложнённые CI скрипты вынесенные аж в отдельную директорию

в хорошем проекте там не должно быть ничего кроме установки зависимостей и cmake –build –install.

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

Да, и кстати, не советую завязываться на существование cmake модулей для jsoncpp

Вообще мне хочется заюзать модуль pkgconfig в симейке и делать всё через него, мне он кажется проще и понятнее.

Не нужен. Проверено.

Вообще, видел такую штуку? Там всё через -runpath работает. И ей не просто не нужен LD_LIBRARY_PATH, она с ним даже отказывается запускаться.

Ну, например несовместимость с libconfig собранным на другой версии компилятора можно исправить либо собрав проект тем же компилятором, либо отказаться от него в пользу libjsoncpp, как сделала я.

И как вы исправите несовместимость в libjsoncpp? Не знаю, к слову, где вы взяли libjsoncpp.so.1, у меня эта библиотека называется libjsoncpp.so.22, и 22 это не просто число, а версия ABI. Любая версия ниже или выше несовместима. В git у них сейчас 24, а реальных дистрах я вижу 19, 20, 21, 22 и да, 0 с 1 которые видимо либо совсем старьё либо чья-то отсебятина. Я повторяю, нет способа слинковаться с shared libjsoncpp чтобы приложение работало со всеми этими сошками.

Это, к слову, только один фактор. Есть ещё версии компиляторов, и разные плюсовые стандартные библиотеки. Вангую что вы собираетесь с libstdc++, хотел бы посмотреть как вы собираетесь запуститься в окружении собранном с libc++, хоть бы даже с теми же ABI версиями библиотек.

Поэтому вся проприетарщина и страдает собирая статику (проблемы переносимости в этом случае сужаются до ABI libc или интерфейса сисколлов ядра, а с этим проблем сильно меньше) или всякие мерзотные flatpak/snap/appimage которые тащат вместе с приложением половину системы. Но всё равно проблем там тонны, в частности я не представляю как они линкуются с libGL, которая может быть от месы, а может быть от проприетарного nvidia-driver. Но у вас же СПО, вам страдать совсем не нужно.

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

Ну повторюсь что если бы вы не публиковали собранное, то и проблемы бы не было, заодно можно было выкинуть ненужный шлак в виде дебиановских метаданных и всякой связанной с ними пакости в CI. Но уж коли публикуете, имело бы смысл разделить треш вендовой сборки и happy path для линуксов. К слову, есть другие источники вендозависимостей, может лучше зайдёт потому что про MXE я первый раз слышу. Например, mingw и vcpkg. Алсо, в appveyor можно собирать и тестировать под винду нативно (в дополнение в Travis; заодно и CI скрипты разделите).

ну а SFGUI вообще ни в каких репах нет, кроме AUR.

Не совсем https://repology.org/project/sfgui/versions, но да, в таком случае можно на первых порах бандлить, а если таки вас начнут опакечивать то в какой-то момент можно будет затребовать внешнюю зависимость и её тоже опакетят.

Вообще мне хочется заюзать модуль pkgconfig в симейке и делать всё через него, мне он кажется проще и понятнее.

Ну стандартный подход если у зависимости нет нативных cmake моделей - искать её через FIND_LIBRARY/FIND_PATH. Дополнительно можно перед ними позвать pkg-config, получить от него хинты и передать в FIND_*, как пример см. штатный CMake’овский FindLibXml2. Чистый pkgconfig имеет много минусов, потому что работает на уровне абстрактных флагов, в не конкретных объектов в виде путей.

про MXE я первый раз слышу. Например, mingw и vcpkg. MXE использует mingw для сборки. Это типо окружение и репа с исходниками и бинарниками, собранными на mingw, можно просто добавить его репу в дебиан и вводить например:

$ apt-get install mxe-x86-64-w64-mingw32.static-libjsoncpp

Либо можно собрать одной командой make jsoncpp в каталоге с mxe всё дерево зависимостей на mingw.

Ну а в vcpkg вроде пакетов нифига нет.

в appveyor можно собирать и тестировать под винду нативно

Фу.

Не знаю, к слову, где вы взяли libjsoncpp.so.1, у меня эта библиотека называется libjsoncpp.so.22, … . В git у них сейчас 24, а реальных дистрах я вижу 19, 20, 21, 22 и да, 0 с 1 которые видимо либо совсем старьё либо чья-то отсебятина.

Глянула, думала что .1 это какая-то отсебятина от разрабов дебиана, оказывается это просто разрабы jsoncpp меняют версию ABI при каждом релизе, хоть и в реадми в гитхабе указали:

Major versions maintain binary-compatibility.

Видимо поэтому разрабы дебиана не обновляют версию jsoncpp в репах.

Если в собранном бинарнике прописан rpath, то LD_LIBRARY_PATH не нужен.

22 это не просто число, а версия ABI. Любая версия ниже или выше несовместима.

Вот тут я был бы поаккуратней в выражениях, т.к. с тем же glibc это слегка 4.2. Т.е. либо ты прочитал их полиси про обратную совместимость(если она есть лол), либо всё же зря вещаешь про общий случай. Согласен, что наглядно, скорее всего правда для этого случая, но не всегда правда. Даже в тех же плюсовых либах можно довольно долго держать обратную abi совместимость для публичных интерфейсов ценой чего-то в духе pimpl.

Ну а в vcpkg вроде пакетов нифига нет.

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

Фу.

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

Глянула, думала что .1 это какая-то отсебятина от разрабов дебиана, оказывается это просто разрабы jsoncpp меняют версию ABI при каждом релизе, хоть и в реадми в гитхабе указали:

Судя по коммит логу они меняют версию ABI когда они ломают ABI. А что кривожопые дебианщики там для себя нафантазировали я даже думать не хочу - они славятся сованием кривых рук в то в чём не разобрались.

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

Я не поддерживаю сборку на MSVC и не буду поддерживать.

Тестировать бинари это одно, а писать скрипты на виндовый батч без нормального unix-like окружения это другое. Ну а запускать с нативной винды какой-нить msys2 мне показалось дико костыльно.

Ну а в vcpkg вроде пакетов нифига нет.

Там есть практически все что нужно.

Я не поддерживаю сборку на MSVC и не буду поддерживать.

Мне импонируют ваши убеждения, среди молодёжи такое не часто встретишь, однако это узкий взгляд. Но одно дело когда MSVC не может собрать корректный код, тогда конечно он идёт лесом. Другое - когда он указывает на реальные проблемы в вашем коде которые пропустили gcc/clang. Несмотря на убогость микрософтовского компилятора, второе намного более вероятно. А уж коли вы против мсячей экосистемы, логичнее не выпускать под неё бинарники.

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

Это чистая правда, не могу передать как я натрахался когда настраивал сборку в appveyor. Но там можно писать на powershell, он есть под linux, можно хотя бы синтаксис проверить, и он, думается мне, более вменяемый чем .bat. Но, справедливости ради, и травис приходится часто отлаживать методом тыка. Поэтому и сборка должка быть из 2 строчек, их не важно на чём писать.

Другое - когда MSVC указывает на реальные проблемы в вашем коде которые пропустили gcc/clang

Для этого лучше наверное анализаторы кода какие-нибудь использовать.
Мне больше не нравится то, что помимо отличий API линукса и винды, и отличий API на разных виндах мне нужно будет ещё и думать о отличиях API между окружением с MSVC и mingw, при этом конечный пользователь никак не заметит результат этой проделанной работы.

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

Поддерживать только свою любимую ОС это как-то узколобо, особенно если нет каких-то технических ограничений, а их нет. Мне важно чтоб игра работала почти у всех (поэтому там кстати использованы древние версии opengl). Юзеру насрать на каком компиляторе собран бинарь, ему нужно чтоб он работал, он работает.

Но там можно писать на powershell

Учить новый скриптовый язык для каждой ОС как-то не особо хочется.

Для этого лучше наверное анализаторы кода какие-нибудь использовать.

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

Мне больше не нравится то, что помимо отличий API линукса и винды, и отличий API на разных виндах мне нужно будет ещё и думать о отличиях API между окружением с MSVC и mingw, при этом конечный пользователь никак не заметит результат этой проделанной работы.

Об этом не надо думать, вы же используете кросс-платформенные API и библиотеки.

Поддерживать только свою любимую ОС это как-то узколобо, особенно если нет каких-то технических ограничений, а их нет.

Поэтому я и предложил собирать ещё и msvc. Проблема которую так можно обнаружить может починить сборку ещё и на какой-нибудь netbsd или haiku. Для которых с CI сложнее.

Учить новый скриптовый язык для каждой ОС как-то не особо хочется.

Я бы не пренебрегал возможностью выучить что-либо новое. Тем более что «выучить» слишком сильное слово для того чтобы посмотреть базовый синтаксис и разобратся как выполнить пару команд.

Об этом не надо думать, вы же используете кросс-платформенные API и библиотеки.

Там есть платформозависимый код, в этом файлике в основном, определение языка системы, папки с конфигом и сохранением (в линуксе XDG_DATA_HOME, в винде %LOCALAPPDATA%), всё такое, делала это всё по феншую (старалась).

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

Поддерживать ещё одно окружение ради нахождения недочётов в коде это как-то странно, соотношение результат/работа будет слишком низким.

Да и хватит об этом спорить, оно и так прекрасно работает на винде, даже лучше чем на линуксе.

Поддерживать ещё одно окружение ради нахождения недочётов в коде это как-то странно, соотношение результат/работа будет слишком низким.

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

Да и хватит об этом спорить, оно и так прекрасно работает на винде, даже лучше чем на линуксе.

Я не спорю, я делюсь опытом. Но не надо - так не надо.