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

Твое призвание - улицу мести, а не линковать, неумный.

man ld | grep DT_SONAME

Почитала, погуглила, получается заставить линкера игнорировать soname невозможно? Я конечно понимаю, что можно отредактировать этот soname у jsoncpp, но не хотелось бы городить такие костыли.

в других дистрибутивах, например арче, файла libjsoncpp.so.1 нет

не хотелось бы городить такие костыли.

В арче нет установочных скриптов, которые могут создать симлинк libjsoncpp.so.1-->libjsoncpp.so?

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

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

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

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

т.к. в других дистрибутивах, например арче, файла libjsoncpp.so.1 нет в пакете jsoncpp

Ага, а в deb нет libjsoncpp.so. Линкуй статику

Спасибо, он у меня почему-то был, я думала, что он с репы, оказывается нет.

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

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

Я имел ввиду симлинк без версии

Ну да, я так и поняла. Я думала что файл libjsoncpp.so у меня был установлен с репы, но в пакете с репы его нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант распаковать и играть, но с динамической линковкой к системным библиотекам не прокатит. Только всё с собой таскать, т.к. в разных дистрибутивах всё по разному. Опакечивай или делай хипстерские flatpack, snap или appimage.

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

это тебе так кажется, пока какой-нибудь шизик не попробует запустить бинарь на дистрибутиве из 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.

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

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

Да, и кстати, не советую завязываться на существование cmake модулей для jsoncpp. У него с cmake циклическая зависимость, поэтому во многих дистрах его собирают meson’ом, при этом никаких cmake модулей не создаётся.

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 имеет много минусов, потому что работает на уровне абстрактных флагов, в не конкретных объектов в виде путей.

собрала

Ну ты «поняла». В интернетах при таких заявлениях нужен пруф.

Ну ладно, man ldconfig.

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

Так уж получилось что я опакетил больше сотни игрушек, занимаюсь этим ещё с тех времён когда был жив linux game tome, и среди них было всё. С веснотом вообще никаких проблем нет. Сложности возникают в основном когда:

• Бандлят зависимости. Их всегда нужно отрывать и переключать на системные, иногда для этого приходится сильно перекорёжить сборку.
• Сборка «умно» определяет опциональные зависимости (т.е., например, нашли openal - собрались с ней; не нашли, но нашли sdl_mixer - собрались с ним; иначе собрались без поддержки звука). Приходится всю эту умность вырезать, потому что сборка должна быть консистентной и повторяемой.
• Игра написана на недоязыках, а иногда ещё и нескольких. Типа hedgewars с игрой на Qt, ланчером на fpc (или наоборот) и сервером на haskell. Или spring с куском AI на жаве.

В остальном же опакечивание - простой до скучности процесс. Взяли шаблон рецепта, вписали туда версию, название и URL, скачали, почитали сборочные скипты, прописали зависимости, исправили очевидные проблемы, добились сборки в чистом окружении, убедились что уважаются системные настройки сборки, собрали на хосте, поиграли, закоммитили и отправили PR’ы в апстрим если есть что. Можно в 5 минут уложиться, если не считать время сборок, в которое можно другими делами заниматься.

Когда я пытаюсь слинковать что-то к файлу libjsoncpp.so, оно линкуется к символической ссылке libjsoncpp.so.1. Мне нужно слинковать именно к libjsoncpp.so, т.к. в других дистрибутивах, например арче, файла libjsoncpp.so.1 нет в пакете jsoncpp. Как это сделать?

Никак — это противоречит собственно тому, зачем эти символические ссылки в принципе придумали. Ну то есть man DT_SONAME, как тут уже написали.

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

в других дистрибутивах, например арче, файла libjsoncpp.so.1 нет в пакете jsoncpp.

Когда у библиотеки меняется soname, это означает, дословно, «библиотека бинарно несовместима с предыдущей версией».

про 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 в репах.

Всегда можно проверять/грузить ручками. dlopen, dlsym

Иногда это правильнее, особенно когда нужна переносимость

Статически линкуй или делай там AppImage/Snap/FlatPak, нет смысла заморачиваться с Linux’овым Dependency Hell.

В линаксе нет депенденси хелла. Зато есть ленивые говнокодеры :)

В линаксе нет депенденси хелла.

Весь этот топик и ещё 30 подобных наглядная демонстрация того, что в Linux’е нет Dependency Hell.

Ну нет же :) Весь этот топик и ещё 30 подобных наглядная демонстрация того, что с девелоперами все плохо.

Весь этот топик и ещё 30 подобных наглядная демонстрация того, что с девелоперами все плохо

Всегда можно проверять/грузить ручками. dlopen, dlsym

Ясно

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

О! Снимаю шляпу, я то уж заподозрил, что ты теоретик, но я больше по проприетарному софту, где собрать бандл или сделать воркэраунд мимо апстрима это нормальная история.

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

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

Мне лень проверять, но по идее флаг -Plibjsoncpp.so вместо -ljsoncpp должен был бы «решить» проблему из хедпоста. Ну т.е. убрать симптомы.

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

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

А почему бы для арча не собирать в арче? Казалось бы, связка CI+ контейнеры прямо создана для подобной задачи

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

$ apt-file search libjsoncpp.so
libjsoncpp-dev: /usr/lib/x86_64-linux-gnu/libjsoncpp.so
libjsoncpp1: /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1
libjsoncpp1: /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1.7.4

В dev-пакете.

О! Снимаю шляпу, я то уж заподозрил, что ты теоретик

Не, так не пойдёт. Шляпой своей можешь подтереться - для тебя лично я абсолютный теоретик. Важно, есть ли тебе что мне возразить и чем свои возражения подкрепить.

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

Я вроде ясно написал что прыжков там нет, никаких «стыковок ABI» вообще быть не может, а автору об этом думать категорически не нужно, для этого и есть мантейнеры.

Мне лень проверять, но по идее флаг -Plibjsoncpp.so

       -P  Inhibit generation of linemarkers in the output from the
           preprocessor.  This might be useful when running the preprocessor
           on something that is not C code, and will be sent to a program
           which might be confused by the linemarkers.

Ещё будут бредовые идеи?

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

Давай-ка лучше ты будешь поаккуратнее и не будешь нести бред про другие библиотеки и сферические pimpl’ы. Если ABI не ломается, то и SOVERSION не меняют. Если меняют, то совместимость сломана, пока не доказано обратное, для каждого случая. А здесь, я всего лишь прочитал git log, где ясно пишут, например, такое:

    * Bump SOVERSION, as some functions were removed
      and structs were changed, as determined by
      libabigail.

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

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

Фу.

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

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

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