LINUX.ORG.RU

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

 , ,


1

2

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

Это сошки либы: https://i.postimg.cc/d3j86zYw/image.png
Тут я собрала пример: https://i.postimg.cc/TwZkB8Fb/image.png
Тут я проверяю его на арче: https://i.postimg.cc/qByQg5Wm/image.png

Ответ на: комментарий от pon4ik

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mirai65536 ()

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

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

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

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

anonymous ()
Ответ на: комментарий от mirai65536

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

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

man лицензия

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

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

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

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

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

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

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

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

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

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

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

slovazap ★★★★★ ()

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

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

man лицензия

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

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

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

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

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

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

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

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

mirai65536 ()
Ответ на: комментарий от slovazap

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

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

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

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

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

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

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

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

slovazap ★★★★★ ()

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от slovazap

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

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

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

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

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

Фу.

mirai65536 ()
Ответ на: комментарий от slovazap

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

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

Major versions maintain binary-compatibility.

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

mirai65536 ()
Ответ на: комментарий от slovazap

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

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

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

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

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

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

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

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

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

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

В любом случае если ты оглянешься за спину на все свои прыжки по опакечиванию и стыковке 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.
slovazap ★★★★★ ()
Ответ на: комментарий от mirai65536

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

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

Фу.

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

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

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

slovazap ★★★★★ ()