Здравствуйте, AlexGin, Вы писали:
AG>Странно, но я пару месяцев назад, столкнулся на практике — с совершенно противоположной ситуацией AG>По ходу разбирания выяснилось, что по-умолчанию здесь поведение Windows и Linux — отличается кардинально...
Мне думается нужно к этому подходить с позиции, что если что-то не сработало как ожидалось, то как сделать так, чтобы сработало. Возьмём для примера более сложный случай, нужно чтобы программа загружала динамические библиотеки из папки ./lib, тогда как исполняемый файл лежит в ./. При этом программа должна быть переносимой. Очевидно, что по умолчанию такое условие не сработает ни в Windows, ни в GNU/Linux, но это ведь не значит, что такое невозможно.
По поводу этого:
Зависимость от библиотеки libqmapcontrol.so имеется, я эту библиотеку неоднократно пересобирал в том же самом Qt Creator.
В том же каталоге, где и файл MyApplication находится четыре файла:
libqmapcontrol.so
libqmapcontrol.so.0
libqmapcontrol.so.0.9
libqmapcontrol.so.0.9.7
То есть, нужный файл ЛЕЖИТ РЯДОМ!
Он откомпилирован с тем же самым GCC, что и мой исполнимый файл!
Хотелось бы обратить внимания на то, что libqmapcontrol.so может быть символической ссылкой. Это как если в Windows скопировать ярлыки вместо библиотек, но это я на всякий случай напоминаю, мало ли. Лучше всего копировать реальный файл и переименовать его соответствующим образом, то есть одна библиотека, один реальный файл, а не куча непонятно чего. Опять же убедиться, что всё находится в рабочем каталоге.
Вторым этапом я бы изучил подгрузку динамических библиотек, этим можно управлять, то есть нужно разбираться в компиляции и так далее. Сказал бы подробнее, но я знаю лишь куда копать, а вот изучать этот вопрос когда-то давно было лень. Qt ещё имеет класс QLibrary, опять же система плагинов, но лучше наверное сначала изучить универсальные методы работы с динамическими библиотеками вне зависимости от проекта.
Немного отвлекусь:
книга Программист-фанатик (Фаулер Чед)
Совет 8.
Будь специалистом
«Как бы вы написали на Java программу, которая уронит виртуальную машину Java?» А в ответ — тишина... «Эй, как вас там? Ау!» «Извините, я вас не понимаю. Вы не могли бы повторить вопрос?» В голосе послышалось отчаяние. По опыту я знал, что повторение вопроса вряд ли чему-то поможет. Поэтому я повторил вопрос медленно и громко. «Как бы вы написали на Java программу, которая
уронит виртуальную машину Java?»
«Э-э-э... прошу прощения. Я раньше никогда этого не делал». «Я уверен, что не делали. Но что там с вопросом: как бы вы написали на языке Java программу, которая НЕ будет приводить к падению JVM?»
Я искал по-настоящему квалифицированных Java-программистов. Перед началом собеседования я попросил этого человека (как и всех остальных, просмотренных за эту неделю) оценить себя по десятибалльной шкале. Он назвал цифру девять. Я ожидал увидеть перед собой звезду. Но если парень так высоко себя ценит, что мешает ему придумать трюк, выводящий виртуальную машину Java из строя?
Это недостаток технической подготовки.
Тем не менее он утверждал, что специализируется на языке Java. Спроси его на вечеринке, чем он зарабатывает, и он ответит: «Я Java-разработчик». Но при этом он оказался не в состоянии ответить на простой вопрос. Я не получил от него даже неправильного ответа. За две с половиной насыщенные собеседованиями недели вербовочной поездки по стране это было правило, а не исключение. На вакантные места претендовали тысячи специалистов по Java, и практически никто из них не мог объяснить, как работает загрузчик Java-классов, или рассказать, каким образом виртуальная машина Java обычно осуществляет управление памятью. Разумеется, все эти знания не нужны тем, кто собирается писать базовый код под чужим руководством. Но приходившие на собеседование люди позиционировали себя как специалисты.
Многие из нас считают, что термин «специализация» означает неумение разбираться в других вещах. Согласно такой трактовке я могу заявить, что моя мать специализируется в Windows, ведь она никогда не работала ни с Linux, ни с OS X. А мои родственники из арканзасской глубинки окажутся специалистами по кантри, потому что они никогда не слушали другой музыки.
В программировании важно досконально понимать детали, это в огромной мере определяют специализацию. Я могу сказать, что не специализируюсь на компиляции. Если человек заморочится, то в принципе он может стать специалистом в каком-нибудь вопросе. В данном вопросе мы пока общаемся не как специалист со специалистом и не как специалист с пользователем, а как пользователем с пользователем.
То как я когда-то компилировал и запускал программы может отличаться от того как их компилирует и запускает другой человек сейчас или даже я сам в настоящее время. Лично я по прежнему не думаю, что поведение Windows и GNU/Linux кардинально отличается. Что действительно часто отличается так это то, как люди привыкли работать в той или иной среде.
Здравствуйте, vsb, Вы писали:
vsb>Не припомню такого в опен сорсе. Чтобы постгрес обновил и он сломался.
ну конечно, если vsb этого не помнит, этого не случается.
Здравствуйте, velkin, Вы писали:
V>Второе правило хорошо работает для разработчиков дистрибутива, но плохо для независимых разработчиков. Скорее всего понадобится какая-нибудь система
Да кто же вам разрабатывать то мешает? Хоть в докерах всё поднимайте.
Главное — убедитесь в том, что в результате ваш софт не ожидает библиотеки рядом с бинарником.
А для этого используйте LD_LIBRARY_PATH.
Здравствуйте, уважаемый velkin, Вы писали:
V>Мне думается нужно к этому подходить с позиции, что если что-то не сработало как ожидалось, то как сделать так, чтобы сработало. Возьмём для примера более сложный случай, нужно чтобы программа загружала динамические библиотеки из папки ./lib, тогда как исполняемый файл лежит в ./. При этом программа должна быть переносимой. Очевидно, что по умолчанию такое условие не сработает ни в Windows, ни в GNU/Linux, но это ведь не значит, что такое невозможно.
Установочный пакет (инсталлятор) программы будет различаться для Linux и Windows — вот очевидное решение.
Причём — совсем НЕ ОБЯЗАТЕЛЬНО делать различные инсталляторы!
Все отличия могут выглядеть как-то так:
V>Зависимость от библиотеки libqmapcontrol.so имеется, я эту библиотеку неоднократно пересобирал в том же самом Qt Creator.
V>В том же каталоге, где и файл MyApplication находится четыре файла:
V>libqmapcontrol.so
V>libqmapcontrol.so.0
V>libqmapcontrol.so.0.9
V>libqmapcontrol.so.0.9.7
V>То есть, нужный файл ЛЕЖИТ РЯДОМ!
V>Он откомпилирован с тем же самым GCC, что и мой исполнимый файл!
Эта проблема уже давно как решена, причём даже несколькими способами!
V>Хотелось бы обратить внимания на то, что libqmapcontrol.so может быть символической ссылкой. Это как если в Windows скопировать ярлыки вместо библиотек, но это я на всякий случай напоминаю, мало ли. Лучше всего копировать реальный файл и переименовать его соответствующим образом, то есть одна библиотека, один реальный файл, а не куча непонятно чего. Опять же убедиться, что всё находится в рабочем каталоге.
Здесь успешно работают два варианта:
— через /usr/lib (просто копируя туда все вышеуказанные файлы под "рутом");
— используя переменную окружения LD_LIBRARY_PATH (со значением '.' — точка) — то есть загружать библиотеки из текущего директория.
V>Вторым этапом я бы изучил подгрузку динамических библиотек, этим можно управлять, то есть нужно разбираться в компиляции и так далее. Сказал бы подробнее, но я знаю лишь куда копать, а вот изучать этот вопрос когда-то давно было лень. Qt ещё имеет класс QLibrary, опять же система плагинов, но лучше наверное сначала изучить универсальные методы работы с динамическими библиотеками вне зависимости от проекта.
Я в курсе насчёт плагинов Qt (QtPlugin).
Применял их пару лет назад. Сделал систему плагинов для проектов в моей прежней конторе.
Это решение хорошее, но оно скорее в стиле "кроссплатформенный_COM". Там много избыточных сущностей (неактуальных для повседневных задач).
В то же время, в описываемом мной проекте требовалось решение в стиле "дешево_и_сердито" — простая DLL (или *.so файл — в терминологии Linux).
Здравствуйте, AlexGin, Вы писали:
AG>Здесь успешно работают два варианта: AG>- через /usr/lib (просто копируя туда все вышеуказанные файлы под "рутом"); AG>- используя переменную окружения LD_LIBRARY_PATH (со значением '.' — точка) — то есть загружать библиотеки из текущего директория.
Здравствуйте, night beast, Вы писали:
NB>+ -Wl,-rpath=.
За такое в порядочных семьях на горох в угол ставят на целый день, а вечером ещё за прохалявленый день подзатыльник дают.
V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. _>И когда найдут очередную уязвимость в библиотеке — система обновится сама, а тебе твой продукт надо будет обновлять отдельно. Так себе вариант.
Обратное тоже справедливо. См долгую историю про OpenSSL, например.
Здравствуйте, Sheridan, Вы писали:
NB>>+ -Wl,-rpath=. S>За такое в порядочных семьях на горох в угол ставят на целый день, а вечером ещё за прохалявленый день подзатыльник дают.
Лучше это, чем LD_LIBRARY_PATH, так что все свое ношу с собой в Linux-e очень даже применим и используется, только в отличие от Windows требует дополнительных телодвижений.
Здравствуйте, Igore, Вы писали:
NB>>>+ -Wl,-rpath=. S>>За такое в порядочных семьях на горох в угол ставят на целый день, а вечером ещё за прохалявленый день подзатыльник дают. I>Лучше это, чем LD_LIBRARY_PATH, так что все свое ношу с собой в Linux-e очень даже применим и используется, только в отличие от Windows требует дополнительных телодвижений.
Горите в аду.
Здравствуйте, velkin, Вы писали:
V>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows.
Это не рабочий способ в линухе: по умолчанию загрузчик не смотрит на динамические библиотеки в одной папке с исполняемым файлом.
Здравствуйте, Sheridan, Вы писали:
S>Главное — убедитесь в том, что в результате ваш софт не ожидает библиотеки рядом с бинарником.
А плагины?
S>А для этого используйте LD_LIBRARY_PATH.
Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь.
Здравствуйте, Skorodum, Вы писали:
S>>Главное — убедитесь в том, что в результате ваш софт не ожидает библиотеки рядом с бинарником. S>А плагины?
Как минимум пара вариантов
1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH
2. /var/lib/libmysupersoftpluginsuperplugin.so
S>>А для этого используйте LD_LIBRARY_PATH. S>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь.
Правильный путь — устанавливать в стандартные пути используя пакетный манагер.
Здравствуйте, Skorodum, Вы писали:
V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта, тоже самое касается Windows. S>Это не рабочий способ в линухе: по умолчанию загрузчик не смотрит на динамические библиотеки в одной папке с исполняемым файлом.
Здравствуйте, Sheridan, Вы писали:
S>Как минимум пара вариантов
Это был намек на то, что фраза "софт ожидает библиотек" больше похожа на описание ситуации с подгрузкой плагинов, когда софт именно что использует относительный путь и контролирует загрузку. Разрешение остальных зависимостей обычно внешние дело, и испольняемым файлом мало контролируется (за исключением rpath или запуска через прокси и LD_LIBRARY_PATH).
S>1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH
1. Нет. LD_LIBRARY_PATH — это грязный хак.
2. Нужны права.
S>2. /var/lib/libmysupersoftpluginsuperplugin.so
1. Нет гарантии отсутсвия конфликтов.
2. Нужны права для установки.
S>>>А для этого используйте LD_LIBRARY_PATH. S>>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь. S>Правильный путь — устанавливать в стандартные пути используя пакетный манагер.
Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе.
Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой?
Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше.
Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win.
И весь более-менее сложный софт использует собственные установщики (тот же QtCreator), пакетные менеджеры отстают на пару лет обычно.
Сам по себе это нормальный подход, особенно учитывая реалии российского использования линухи (военные и т.п.), просто фраза пользователя velkin не верная.
Кстати интересно, а вдруг есть. Например вот в такой схеме нумерации версий:
major_ver.minor_ver.fix_ver.build_data
major_ver — с каждой циферкой считай другой проект, api от между major версиями меняется как угодно
minor_ver — с увеличением методы/объекты в api только добавляются, существующие методы не удаляются и не изменяются. т.е. все полагают что абсолютно безопасно заменять версию 3.1 на 3.2
fix_ver — фиксы которые накатили на конкретную версию, ничего вообще не меняется кроме исправления ошибок
build_data — любой набор цифер который имеет смысл для разработчика, нет нужды даже быть упорядоченным, если в систему прилетает (например компилируется). По-умолчанию каждый новый билд затирает старый без проблем если не указано иное в каких-то настройках.
Единый репозиторий для всех библиотек, и ОС при запуске полагается только на эту структуру. То есть смело подставляет версию 3.2 вместо 3.1
Если админу прям очень надо чтобы ликовка была именно с 3.1 несмотря на то что уже есть 3.2 — надо указать в настройках (например в файле admin.config рядом с приложением). Само приложение ни при инсталляции ни как-то ещё создать этот файл не может, чтобы у разрабов не было шанса захардкодить конкретную зависимость для упрощения своей жизни.
Имхо, пару лет косорукие создатели библиотек будут отгребать от страдающих создателей программ, а потом длл-хелл отступит. Разработчики библиотек приспособятся соответствовать, а проекты в которых бардак и регулярно надо лазить в admin.config — будут нелюбимы и станут непопулярны. Или я ошибаюсь и в этой системе есть заметный изъян?
_>major_ver.minor_ver.fix_ver.build_data
_>major_ver — с каждой циферкой считай другой проект, api от между major версиями меняется как угодно _>minor_ver — с увеличением методы/объекты в api только добавляются, существующие методы не удаляются и не изменяются. т.е. все полагают что абсолютно безопасно заменять версию 3.1 на 3.2 _>fix_ver — фиксы которые накатили на конкретную версию, ничего вообще не меняется кроме исправления ошибок
Это называется semantic versioning и не работает нигде. Потому что версии от балды назначаются людьми, а автоматическую верификацию натянуть на это дело не получится.
_>Если админу прям очень надо чтобы ликовка была именно с 3.1 несмотря на то что уже есть 3.2 — надо указать в настройках (например в файле admin.config рядом с приложением). Само приложение ни при инсталляции ни как-то ещё создать этот файл не может, чтобы у разрабов не было шанса захардкодить конкретную зависимость для упрощения своей жизни.
1. Линковку должен решать не админ.
2. Есть ненулевое количество случаев, когда разработка зависит от конкретной версии библиотеки
_>Имхо, пару лет косорукие создатели библиотек будут отгребать от страдающих создателей программ, а потом длл-хелл отступит.
Не отступит. Semantic versioning уже скоро 10 лет существует в node.js и npm. Легче от этого не становится.
Здравствуйте, Skorodum, Вы писали:
S>>Как минимум пара вариантов S>Это был намек на то, что фраза "софт ожидает библиотек" больше похожа на описание ситуации с подгрузкой плагинов, когда софт именно что использует относительный путь и контролирует загрузку. Разрешение остальных зависимостей обычно внешние дело, и испольняемым файлом мало контролируется (за исключением rpath или запуска через прокси и LD_LIBRARY_PATH).
Не вижу разницы между зависимостями и собственными либами. rpath в любом случае грязный хак, делающий невозможным управление либами приложения
S>>1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH S>1. Нет. LD_LIBRARY_PATH — это грязный хак.
Нет, это стандартный метод указания софту где искать библиотеки, по каким путям. Есть PATH — для бинарников и LD_LIBRARY_PATH — для библиотек.
S>2. Нужны права.
Это совершенно не проблема.
S>>2. /var/lib/libmysupersoftpluginsuperplugin.so S>1. Нет гарантии отсутсвия конфликтов.
Есть, если не называть либы именами типа libplugin.so или libextention.so
S>2. Нужны права для установки.
Это совершенно не проблема.
S>>>>А для этого используйте LD_LIBRARY_PATH. S>>>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь.
Кем не рекомендован? Озвучте весь список пожалуйста
S>>Правильный путь — устанавливать в стандартные пути используя пакетный манагер. S>Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе.
Это проблема?
S>Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой?
Их разработчики.
А ты, как разработчик софта, выбери несколько дистрибутивов и автоматизируй сборку пакетов об тот же fpm
S>Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше.
Вот сейчас у меня настолько подгорело что я даже не знаю какие слова тут написать.
Бредовая идея. Бредовый софт. В линупсах так не делают. Ты машешь флагом Спартака на трибунах Динамо.
S>Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win.
нираспарсил...
S>И весь более-менее сложный софт использует собственные установщики (тот же QtCreator),
Такого софта — единицы.
S>пакетные менеджеры отстают на пару лет обычно.
Поправочка: официальные репозитории отстают в силу необходимости соблюдения стабильности дистрибутива.
Тебе ничего не мешает иметь собственные репозитории для своих продуктов под популярные дистрибутивы, как это делает раббит, графана, прометей и так далее.
Здравствуйте, Слава, Вы писали:
С>Да, это такой софт, который даже виртуалки не любит. Вроде freeswitch.
Я засунул. Даже свой докерфайл, из исходников собирается, на Alpine.
Хорошо работает на ~ 8 линий
В свою очередь, прошу конкретики. Что именно у тебя не запускается?
Чужие байки я и сам могу посмотреть, некоторые и шнурки завязать не могут. Но это же не значит, что они незавязываемы и это нужно переписывать как факт
Здравствуйте, Sheridan, Вы писали:
S>Не вижу разницы между зависимостями и собственными либами.
Разница между плагинами и бинарными зависимостями принципиальна: плагины опциональны и приложение может их искать по любым путям.
S>rpath в любом случае грязный хак, делающий невозможным управление либами приложения
Глупость. rpath добавляет новое место для поиска зависимостей, но не отменяет остальные. Это именно что стандартное решение.
S>>>1. /var/lib/mysupersoft/plugins + LD_LIBRARY_PATH S>>1. Нет. LD_LIBRARY_PATH — это грязный хак. S>Нет, это стандартный метод указания софту где искать библиотеки, по каким путям. Есть PATH — для бинарников и LD_LIBRARY_PATH — для библиотек.
Нет, нет, нет. Это — не стандартный метод. Это хак для откладки.
1. Использование LD_LIBRARY_PATH при нормальной установке приложения — прямой путь к конфликтам и проблемам с безопасностью.
2. Для установки переменной надо либо глобально ее менять при установке приложения (ужос-ужос), либо использовать скрипт или для запуска (ужос).
S>>>2. /var/lib/libmysupersoftpluginsuperplugin.so S>>1. Нет гарантии отсутсвия конфликтов. S>Есть, если не называть либы именами типа libplugin.so или libextention.so
Нет гарантии отсутсвия конфликтов.
S>>>>>А для этого используйте LD_LIBRARY_PATH. S>>>>Это хак не особо рекоменнуемый для продакшена. Конфигурационные файлы правильный путь. S>Кем не рекомендован? Озвучте весь список пожалуйста
Здравый смысл и ну и например Оракл.
Ну или маны почитай и обрати внимание, когда LD_LIBRARY_PATH игнорируется.
S>>>Правильный путь — устанавливать в стандартные пути используя пакетный манагер. S>>Да хоть так, суть в том, что твой пакетный менеджер должен обновить /etc/ls.so.conf или что-то в этом духе. S>Это проблема?
В общем случае — нет, разговор про то, что менять глобальные переменные при установке приложения — очень плохая идея.
S>>Ну и проблема в пакетных менеджерах: кто будет заниматься их поддержкой? S>Их разработчики. S>А ты, как разработчик софта, выбери несколько дистрибутивов и автоматизируй сборку пакетов об тот же fpm
Да делать больше нечего. Нормально собранное приложение и так прекрасно работает на всех целевых линухах. Единственное действие которое надо сделать пользователю — добавить права на выполнение.
S>>Я, как разработчик, делаю AppImage, который работает везде без необходимости рутовых прав для установки. И совершенно пофиг на лишние мегабайты у пользователя из-за повторяющихся библиотек, зато количество головной боли во вселенной на порядки меньше. S>Вот сейчас у меня настолько подгорело что я даже не знаю какие слова тут написать. S>Бредовая идея. Бредовый софт. В линупсах так не делают.
Т.е. разработчики обязаны поддерживать все пакетные менеджеры?
S>Ты машешь флагом Спартака на трибунах Динамо.
Ну твой фанатизм известен
S>>Дальше мантейнеры пакетных мендежеров могут устанавливать как угодно. А можно и без них, Win-Win. S>нираспарсил...
Да вроде все просто: если тебе надо, то возьми мое приложение и сделай пакет, чтобы что-то вроде
sudo apt install super-pupper
работало. Но оно прекрасно работает и без этого. Скачал и запустил.
S>>И весь более-менее сложный софт использует собственные установщики (тот же QtCreator), S>Такого софта — единицы.
Такого софта вагон и маленькая тележка, для любого софт который активно развивается такой подход будет предпочтительнее.
Для утилит и программ которые "просто работают" и обновляются раз в 5 лет пакетные менеджеры лучше подходят.
S>>пакетные менеджеры отстают на пару лет обычно. S>Поправочка: официальные репозитории отстают в силу необходимости соблюдения стабильности дистрибутива. S>Тебе ничего не мешает иметь собственные репозитории для своих продуктов под популярные дистрибутивы, как это делает раббит, графана, прометей и так далее.
Это какой-то птичий язык. Я использую программы QtCreator/Chrome/Steam/etc, я их беру с офф. сайта разраотчиков и все работает.
