LINUX.ORG.RU
ФорумTalks

Linux-дистрибутивы и дистрибьюция коммерческого ПО

 , , dll hell, ,


2

3

На ЛОРе часто можно услышать, мол программисты не клепают коммерческий и профессиональный софт под дистрибутивы Linux не потому что у нас нет нормальных систем дистрибьюции ПО, работающих стандартов и твёрдого API на который можно положиться, а потому что это всё заговор проприетарщиков, конспирология и рептилоиды.

Давеча понадобилось мне открыть несколько изображений весьма специфичного и редкого формата – MBM (MultiBitMap), который в древние века предназначался для хранения нескольких растровых изображений формата BMP и их масок в одном файле со сжатием. Этот формат был распространён в Symbian OS и его предке EPOC, по сути он был примитивным аналогом современных форматов вроде ICNS из macOS или ICO из Windows.

Стандартные программы вроде GIMP’а или Image Viewer’а в Fedora 33 открывать подобные файлы не умеют. В репозиториях дистрибутива тоже ничего путного не нашлось (хотя может быть плохо искал), а вот лёгкое гугление показало что открыть такой файл может просмотрщик изображений XnView.

Программа XnView является проприетарной и коммерческой, хоть и бесплатной для личного использования. Потому она и отсутствует в репозиториях. Но не беда! Идём на официальный сайт программы в раздел загрузок и видим, что её автор не забил (как это обычно бывает) на Linux, а заботливо приготовил помимо DEB-пакетов несколько TAR-ball’ов и даже самодостаточный пакет AppImage соорудил. Вот ведь молодец какой.

Сперва скачиваем AppImage, потому что сам Linus Torvalds с официального сайта AppImage кричит нам «This is just very cool.», а потому предвкушая быстрое решение своей проблемы, делаем:

$ chmod +x XnView_MP.glibc2.18-x86_64.AppImage
$ ./XnView_MP.glibc2.18-x86_64.AppImage 
/tmp/.mount_XnView3k4rdy/usr/XnView/XnView: symbol lookup error: /lib64/libkrb5.so.3: undefined symbol: krb5int_push_fscreatecon_for, version krb5support_0_MIT

Ой. Вот такая у нас хвалёная «самодостаточность». Ну ладно, может быть разработчики как-то криво собрали AppImage, бывает, я сам как-то раз криво их собирал, ничего. Технология-то ещё совсем свежая и молодая, 17 лет всего ей.

Ладно, скачиваем TAR-ball. Тут на форуме некоторые линуксоды постоянно кричат, мол пусть разработчики коммерческого софта своё ПО в TAR-ball’ах распространяют, а то пакеты делают только для Ubuntu или вообще их не делают. Если верить им, то случае архива всё должно пройти максимально гладко.

$ tar -xf XnViewMP-linux-x64.tgz
$ ./XnView
./XnView: error while loading shared libraries: libQtAV.so.1: cannot open shared object file: No such file or directory

Хм. Странно. Разработчики забандлили в архив целый Qt, но забыли положить библиотеку, которая может отсутствовать в репозиториях каких-нибудь маргинальных дистрибутивов, сподвигая линуксоидов их использующих заниматься увлекателейшим поиском исходников библиотеки и последующей компиляцией. Но, к счастью, у нас же современная Fedora, так что продолжаем:

$ sudo dnf install libqtav
$ ./XnView
./XnView: error while loading shared libraries: libQtAVWidgets.so.1: cannot open shared object file: No such file or directory

Это уже начинает надоедать. Ладно:

$ sudo dnf install libqtavwidgets
$ ./XnView
./XnView: /lib64/libQt5Network.so.5: version `Qt_5_PRIVATE_API' not found (required by ./XnView)

Ясно, понятно. И как теперь быть? Да просто скачиваем с официального сайта XnView версию для Windows и запускаем её:

$ sudo dnf install wine
$ unzip XnViewMP-win-x64.zip
$ wine XnView.exe

Программа работает, нужное мне изображение открывается, проблема решена. А если бы я не трахался с попытками запуска нативных Linux’овых версий, то решил бы её ещё быстрее.

Послесловие

Неужели великий Джон Кармак был прав, когда говорил о том, что развитие и улучшение WINE – лучший путь для Linux-дистрибутивов, а продавливание нативных портов различных коммерческих программ обречено на провал с этим зоопарком ВСЕГО?

И ведь если бы эти пакеты XnView были собраны на отвались, так нет же, авторы программы постоянно собирают баг-репорты ([1], [2]) пользователей Linux и стараются помочь всем этим несчастным людям.

Вдвойне обидно, что XnView это как раз тот редкий случай, когда программа изначально разработанная специально для Linux (и ещё IRIX) вышла за пределы этой операционной системы и стала популярна на Windows и macOS. Это какой-то позор.

★★★★★

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

Ну так это очевидно, но ты вот полез с коричневой темой и вот с таким ЧСВ. Довольно типично для местной аудитории.

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

В последствии отказался от них в пользу статической сборки

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

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

если не будет лень, то проверю завтра на федоре
но, подозреваю, такое там вполне может быть, и достаточно удалить у XnView ./lib/libcrypto.so ./lib/libcrypto.so.1.1

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

но на его удачу скрипт тоже не запустился

Несомненно, в том что программа не запустилась виноват конечно же некомпетентный ТС, а ещё автор-неосилятор программы не знающий матчасть, а ещё авторы раздутых тулкитов вроде Qt, но никак не дистростроители Linux’а, которые за 20 с лишним лет не смогли создать какую-нибудь базовую подсистему-прослойку для совместимости между различными Linux-дистрибутивами на основе хотя бы на основе того же полудохлого LSB, выкинув из него всю ахинею в виде захардкоженных RPM-пакетов и Qt 3.

EXL ★★★★★
() автор топика

Ой. Вот такая у нас хвалёная «самодостаточность». Ну ладно, может быть разработчики как-то криво собрали AppImage, бывает, я сам как-то раз криво их собирал, ничего. Технология-то ещё совсем свежая и молодая, 17 лет всего ей.

AppImage в корне своей идеи никогда работать нормально не будет.

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

да я просто порофлил с твоих попыток, и не лень же было …

но те, кто так распространяют софт - да - делают глупо

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

…дабы обосраться в полный рост…

О боже…

…но на его удачу скрипт тоже не запустился…

:) Прикольно вы умные друг с другом общаетесь :) лолксы торт!

PS.

кто так распространяют софт - да - делают глупо

Я извиняюсь, а как неглупо распространять? @a1batross?

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

это в которой практически нет софта на Qt? Чему ж ты удивляешься?

Настолько нет, что у них даже официальная программа для записи образов на флешку на Qt написана: https://github.com/FedoraQt

Вот в gentoo у меня софтина работает.

Откуда именно? Из AppImage, из TAR-ball’а, из Gentoo’вского аналога AUR’а?

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

но, подозреваю, такое там вполне может быть, и достаточно удалить у XnView ./lib/libcrypto.so ./lib/libcrypto.so.1.1

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

AppImage для Fedora тоже можно «починить» таким вот рецептом:

$ ./XnView_MP.glibc2.18-x86_64.AppImage --appimage-extract

$ ./squashfs-root/AppRun 
/home/exl/Downloads/squashfs-root/usr/XnView/XnView: symbol lookup error: /lib64/libkrb5.so.3: undefined symbol: krb5int_push_fscreatecon_for, version krb5support_0_MIT

$ rm -Rf squashfs-root/lib/
$ rm -Rf squashfs-root/usr/lib/

$ ./squashfs-root/AppRun 
/home/exl/Downloads/squashfs-root/usr/XnView/XnView: symbol lookup error: /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b

$ rm squashfs-root/usr/XnView/lib/libcrypto.so*
$ ./squashfs-root/AppRun
OK

$ curl -LOJ https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage
$ chmod +x appimagetool-x86_64.AppImage
$ ./appimagetool-x86_64.AppImage squashfs-root

$ ./XnView_MP-x86_64.AppImage

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

но те, кто так распространяют софт - да - делают глупо

А как иначе? Вот захотел автор XnView, например, собрать RPM-пакет для Fedora 33, взял OBS. Вышла Fedora 34, пакет превратился в тыкву.

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

Вот захотел автор XnView, например, собрать RPM-пакет для Fedora 33, взял OBS. Вышла Fedora 34, пакет превратился в тыкву.

там как бы есть 34-я, и даже Rawhide

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

Изначально из tarball, потом из подправленного ebuild из bugzilla, который качал tarball. И то там в скрипте установки зависимости больше прописаны для желающих сделать unbundle для библиотек.

Ты хоть бы версию указывал. Не говоря о том, что для linux нет xnview. Есть xnviewmp.

Эта твоя утилита для записи идёт в базовой поставке workstation?

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

как иначе? Вот захотел автор XnView, например, собрать RPM-пакет для Fedora 33, взял OBS. Вышла Fedora 34, пакет превратился в тыкву.

А в чём такая дистроспецифичность получается? Вроде программа для более старой версии должна работать на более свежей, не?

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

OBS

Но там ведь при установке пакета скрипты могут исполняться. Любые, от рута. Я ж целиком доверяю систему какому-то хрену с горы, так?

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

ну во-первых, скрипты видно в пакете, и можно запустить установку без скриптов или просто вытащить файлы

а во-вторых, речь про закрытый софт, так ведь?

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

или просто вытащить файлы

А, забыл, тогда ок. Тогда тут претензий нет.

Ну да, конечно про закрытый. (я не понял?)

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

если про закрытый, то почему скомпилированному коду доверяем, а скриптам (от того же автора) - нет?

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

Ты хоть бы версию указывал. Не говоря о том, что для linux нет xnview. Есть xnviewmp.

Так версия последняя с сайта, доступная для Linux. Касательно XnView и XnView MP по сути это одно и то же, просто новая версия XnView стала XnView MP, вот и всё. Директория и исп. файл называются всё равно XnView.

Эта твоя утилита для записи идёт в базовой поставке workstation?

Они её на официальной странице дистра рекомендуют:

https://getfedora.org/en/workstation/download/

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

почему скомпилированному коду доверяем

А я (из-под «себя», обычного юзера) не доверяю скомпилированному коду. Я его запускаю из-под (условно) junkuser. Так – да, более-менее доверяю (игры с гога и пр.). И у junkuser нет доступа к файлам моего обычного юзера (ипрописаны правила фаевола).

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

А в чём такая дистроспецифичность получается? Вроде программа для более старой версии должна работать на более свежей, не?

Про 33 => 34 это больше «гипербола», а дистроспецифичность вот как раз из-за кучи мелочей и отличий в сборке Qt, OpenSSL, директорий библиотек (lib64 vs x86_64-linux-gnu) и др.

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

Рекомендовать они могут что угодно. Но в самом дистрибутиве оно есть?

Если у тебя претензии к deb или rpm пакету, то ок, а бинарный tarball не обязан все зависимости тащить.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)

у нас нет нормальных систем дистрибьюции ПО, работающих стандартов и твёрдого API на который можно положиться

Строго говоря, всё так. Единственное что есть, это forward compatibility в гнутом стеке (libc, libdl, libm, librt, libpthread, libgcc_s, libstdc++) и честное слово Линуса не ломать семантику сисколов. Всё остальное надо майнтейнить за свой или чей-то ещё счёт в отдельной системе портов, не связанной с дистрибутивом. Собственно, под винду так и делают (технически достигается разными способами, сюда подпадают и MSYS2, и cygwin, и пакеты mingw-* для кросскомпиляции из Linux, самые разные пакетные менеджеры для C++ и даже тупо своя Qt собранная в C:\qt, всё зависит от бюджета). Под Linux свою систему портов, не связанную с дистрибутивом, организовать не то чтобы невозможно, но технически сложнее, так как компиляторы, линкеры и лоадеры по умолчанию просматривают /usr, и с монстрами типа Qt гарантировать что ты случайно не втащил паразитную зависимость с хоста, становится сложновато.

Ну и человеческий фактор даже при наличии бюджетов тоже нельзя списывать - большинство разработчиков и менеджеров придерживается нигилистического подхода (время потраченное на сборку - зря потраченное время) и все эти промежуточные слои им до одного места, пусть хоть на деревьях растут.

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 1)

Не давать проприетарному шлаку работать - это позор? Я думаю это офигенно.

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

Потому и неудобный. Разработчики SUSE сделали очень хороший сервис, который действительно недооценён. Был бы их дистрибутив более популярен, тогда может быть всё было несколько иначе.

EXL ★★★★★
() автор топика

Просто автор сборок под Linux латентный (а может, и актуальный) слаковод - он подразумевает, что пакет, к примеру, Qt5, установленный в вашей системе, идёт сразу со всеми субмодулями, а не в шинковке, как в «немаргинальных» дистрибутивах.

В Slackware программа работает, и в stable, и в -current. И .tgz, и appimage.

lagavulin16
()
flatpak install XnViewMP
Поиск похожих запросов...
Найдены похож(ая/ие) ссылк(а/и) для 'XnViewMP' в репозитории 'flathub' (system).
Использовать этот репозиторий? [Y/n]: y
Найдена ссылка 'app/com.xnview.XnViewMP/x86_64/stable' в репозитории 'flathub' (system).
Использовать эту ссылку? [Y/n]: y
...
Перейти к системной установке с этими изменениями? [Y/n]: y 

Проблема решена.

qtm ★★★
()

Разработчики забандлили в архив целый Qt, но забыли положить библиотеку

…с которой они в тарбольной поставке решили слинковаться динамически. Виноват линукс.

Princesska ★★★★
()

Ладно, скачиваем TAR-ball. Тут на форуме некоторые линуксоды постоянно кричат, мол пусть разработчики коммерческого софта своё ПО в TAR-ball’ах распространяют, а то пакеты делают только для Ubuntu или вообще их не делают.

Так в тарболлах с сорцами же =)

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

Проблема решена.

https://flathub.org/apps/details/com.xnview.XnViewMP

App Not Found

No app with the ID com.xnview.XnViewMP was found on Flathub. Try searching for the app using the search bar above.


Проблема в том, что этот пакет похоже неофициальный. Если бы его сами авторы XnView предлагали для установки со своего сайта, тогда был бы другой разговор.

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

В смысле app not found? А что я тогда себе ставил вчера? :-)

Пакет неофициальный. Но по факту никаких проблем с дистрибуцией проприетарщины нет. Можно собирать флатпак и не париться по поводу дистросовместимости. Проблемы с дистрибуцией только у афтырей XnView.

qtm ★★★
()
Последнее исправление: qtm (всего исправлений: 1)

но забыли положить библиотеку,

Нет, не забыли

xDShot ★★★★★
()

xnview.sh шель скрипт есть в tgz архиве, там прописаны все LD_LIBRARY_PATH и QT_PLUGIN_PATH. Отличный вброс 👍

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

В смысле app not found? А что я тогда себе ставил вчера? :-)

У них там с серваками что ли проблемы какие-то были. Сейчас норм.

EXL ★★★★★
() автор топика

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

Harald ★★★★★
()

Поддержу ТС. На void тарбол тоже не осилил, какой-то куте-плугин так и не нашелся. Но апимедж таки запустился.

Psilocybe ★★★★
()

Дистрибуция Qt5 это вообще очень интересный вопрос. Например однажды я запустил Unigine Superposition. Там лаунчер на Qt5. Не запускается, и причин не называет. Не помню точно как, но я нашёл отладочную информацию. Не найдена библиотека libGLdispatch. Оказывается, эта библиотека идёт с драйвером NVIDIA, но почему-то она не установилась на мой компьютер вместе с драйвером. Не знаю почему. Возможно, потому что я отказался от использования GLvnd при установке драйвера. И то ли библиотеки Qt5, распространяемые с программой, то ли системный libGL, требует libGLdispatch. Причём ни одна другая программа не требует.

Компилировал я Qt5 сам. Получились красивые бинарники. Почему-то при использовании этих бинарников не работает клавиатура. Почему? А потому что, при компилировании, Qt попросил xkbcommon. Компилирую xkbcommon. Он просит libxcb >= 1.10, а у меня только 1.5. xkbcommon компилируется без поддержки x11. А раз он компилируется без поддержки x11, то клавиатура в приложениях Qt5 не работает.

Ладно, обновляю libxcb до нужной версии, пересобираю xkbcommon с поддержкой x11, пересобираю Qt5. И что вы думаете? Не работает. Ругается в консоль что-то про XKB_CONFIG_ROOT. Если выполнить то, что предлагают в сообщении об ошибке, всё начинает работать. И, как я понимаю, система это запомнит, и больше ничего делать не надо. Но блин, почему первый запуск-то глючит?

Добавил опцию при сборке:

	-xkb \
	-system-xkbcommon \
	-xkb-config-root /usr/share/X11/xkb \

Стало нормально и при первом запуске тоже. Ну блин, а почему сразу не работало нормально? И что кстати делает строка:

%define xkbconfigroot %(pkg-config --variable=xkb_base xkeyboard-config)

, которая стоит в SPEC-файле перед ./configure?

И кстати, если выставить -qt-xkbcommon вместо -system-xkbcommon, я надеялся что в этом случае удастся обойтись без обновления libxcb. А вот нет, нифига. А опция -qt-xcb вместо -xcb по-идее должна подтянуть libxcb 1.10, но нет, нифига, она подтягивает только xcb-util, но не libxcb!

Дальше. Я комплировал Qt5 как при помощи SPEC-файла с установкой в /usr, так и вручную. RPM-ка в итоге нормально работает, а мой результат компиляции вручную... В общем, я запускаю мою программу на Qt5 на другом компьютере, и там квадратики вместо символов. Запускаю из командной строки, и узнаю, что не найдена директория /home/zenitur/qt5-build/src/fonts. Притом что на целевом компьютере директории /home/zenitur и близко нет. Как оно так скомпилировалось, что местоположение шрифтов оказалось захардкожено на мой «хомяк»?

И это не говоря уж о неободимости таскать вместе с программой - файл libqxcb.so и директорию platforms. Вот было же так просто во времена Qt4, когда можно было просто положить libQt4Core и libQt4Gui, и всё!

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

И что кстати делает строка:

Наверное устанавливает в переменную окружения (?) xkbconfigroot значение выхлопа команды pkg-config --variable=xkb_base xkeyboard-config.

Дальше. Я комплировал Qt5 как при помощи SPEC-файла с установкой в /usr, так и вручную. RPM-ка в итоге нормально работает,

Путь сборки Qt через RPM-пакет полезен и удобен когда тебе нужно внести изменения в системный Qt, использование сборочной системы RPM-пакетов (DEB, и любой другой тоже) позволяет добиться консистентности и ты точно уверен что все патчи дистростроителей накладываются перед сборкой.

В общем, я запускаю мою программу на Qt5 на другом компьютере, и там квадратики вместо символов. Запускаю из командной строки, и узнаю, что не найдена директория /home/zenitur/qt5-build/src/fonts. Притом что на целевом компьютере директории /home/zenitur и близко нет. Как оно так скомпилировалось, что местоположение шрифтов оказалось закардкожено на мой «хомяк»?

Обычно такое бывает, если Qt у тебя собрался без поддержки fontconfig.

И это не говоря уж о неободимости таскать вместе с программой - файл libqxcb.so и директорию platforms. Вот было же так просто во времена Qt4, когда можно было просто положить libQt4Core и libQt4Gui, и всё!

А ещё plugins/imageformats и др. Да, с Qt 4 было очень просто, поскольку там не было такой абстракции, как QPA. А вот Qt 5 стал более модульным и сложным в деплое. В Qt 6 модульность увеличили ещё сильнее. С точки зрения правильности архитектуры Qt на правильном пути. Если раньше в Qt 4 захардкоживался xcb-backend и тупо всё, чтобы что-то изменить тебе нужно было пересобирать весь Qt, то в Qt 5 с внедрением QPA портирование фрейморка на другие технологии выполнить гораздо проще. Сообщество начало переходить на Wayland? Через QPA реализуется поддержка этого протокола и при запуске программа на Qt выберет либо libxcb.so, либо libqwayland-egl.so в зависимости от обстоятельств. Захотели реализовать какой-нибудь Vulkan-backend или OpenGL-backend рендеринг Qt Widgets? Нет проблем сделать его в рамках QPA. И т. д.

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

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

> Обычно такое бывает, если Qt у тебя собрался без поддержки fontconfig.

Кстати да, поддержку fontconfig я починил позднее. Вот в чём была проблема.

> А ещё plugins/imageformats

Ууу, злоба берёт. Ещё и расположить всё по феш-шую в правильных местах.

> Наверное устанавливает в переменную окружения

А ведь и правда. Включу эту переменную вместо указания конкретной директории.

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

В 2015 году я хотел компилировать ПО в CentOS 5, чтобы был максимально большой охват дистрибутивов Linux, в которых оно заработает. Например скромные требования к версии Glibc.

Нашёл инструкцию, как скомпилировать Qt5 под CentOS 5. Там надо было поднять GCC минимум до версии 4.4, а лучше 4.8 (из репозитория devtoolset), наложить пару патчей, и подготовить сборочное окружение.

Сейчас CentOS 5 устарела, да и CentOS 6 тоже уже не поддерживается, поэтому я таким больше не занимаюсь.

Потом я компилировал Qt5 для openSUSE 11.4, на которой тогда сидел (последняя суся с GNOME2). SRPM-пакеты, предназначенные для актуальной тогда версии 12.3, скомпилировались без проблем, все зависимости в системе успешно нашлись.

Позже я попробовал скомпилировать под SLES 11, и тут возникли проблемы. Первая проблема это синтаксис SPEC-файла, который за это время изменился, и пришлось вносить изменения. Вторая это старая версия libxcb 1.1 в системе, которую пришлось обновлять.

Вот так получилось

ZenitharChampion ★★★★★
()

Продолжаем.

В теме Посоветуйте замену stardict'у Эдик спросил об аналоге программы StarDict, коей является GoldenDict.

Идём на официальный GitHub и качаем AppImage:

$ curl -LOJ https://github.com/Abs62/goldendict/releases/download/continuous/GoldenDict-b2e6739-x86_64.AppImage
$ chmod +x GoldenDict-b2e6739-x86_64.AppImage
$ ./GoldenDict-b2e6739-x86_64.AppImage
Segmentation fault (core dumped)

$ gdb ./GoldenDict-b2e6739-x86_64.AppImage

Thread 3 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 161405]
0x00007ffff0f385d2 in ?? () from /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.8-4.fc33.x86_64 fontconfig-2.13.92-12.fc33.x86_64 freetype-2.10.4-1.fc33.x86_64 glib2-2.66.8-1.fc33.x86_64 glibc-2.32-6.fc33.x86_64 gmp-6.2.0-5.fc33.x86_64 libICE-1.0.10-4.fc33.x86_64 libSM-1.2.3-6.fc33.x86_64 libX11-1.6.12-3.fc33.x86_64 libXau-1.0.9-4.fc33.x86_64 libXcursor-1.2.0-3.fc33.x86_64 libXfixes-devel-5.0.3-12.fc33.x86_64 libXi-devel-1.7.10-4.fc33.x86_64 libXinerama-1.1.4-6.fc33.x86_64 libXrandr-1.5.2-4.fc33.x86_64 libbrotli-1.0.9-3.fc33.x86_64 libcom_err-1.45.6-4.fc33.x86_64 libffi-3.1-26.fc33.x86_64 libgcc-10.3.1-1.fc33.x86_64 libglvnd-1.3.3-1.fc33.x86_64 libglvnd-glx-1.3.3-1.fc33.x86_64 libgpg-error-1.41-1.fc33.x86_64 libpng-1.6.37-6.fc33.x86_64 libstdc++-10.3.1-1.fc33.x86_64 libuuid-2.36.1-1.fc33.x86_64 libxcb-1.13.1-5.fc33.x86_64 openssl-devel-1.1.1k-1.fc33.x86_64 p11-kit-0.23.22-2.fc33.x86_64 pcre-8.44-2.fc33.x86_64 zlib-1.2.11-23.fc33.x86_64
(gdb) bt
#0  0x00007ffff0f385d2 in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#1  0x00007ffff0f38965 in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#2  0x00007ffff0f38ae5 in QSslCertificate::fromData(QByteArray const&, QSsl::EncodingFormat) () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#3  0x00007ffff0f39259 in QSslCertificate::fromPath(QString const&, QSsl::EncodingFormat, QRegExp::PatternSyntax) ()
    at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#4  0x00007ffff0f49fa9 in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#5  0x00007ffff0f4984d in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#6  0x00007ffff0f384ab in QSslCertificate::QSslCertificate(QByteArray const&, QSsl::EncodingFormat) () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#7  0x00007ffff0f3fd54 in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#8  0x00007ffff0f408a1 in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#9  0x00007ffff0f3b81d in QSslConfiguration::defaultConfiguration() () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtNetwork.so.4
#10 0x000000000050e80d in InitSSLRunnable::run() ()
#11 0x00007ffff09abe0a in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtCore.so.4
#12 0x00007ffff09b8e3c in  () at /tmp/.mount_GoldenwE80FP/usr/bin/../lib/libQtCore.so.4
#13 0x00007ffff09253f9 in start_thread () at /lib64/libpthread.so.0
#14 0x00007ffff05074c3 in clone () at /lib64/libc.so.6

Что, авторы этой программы тоже рукожопы?

EXL ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.