Romul81
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Svirepov
Цитата:
В этом плане hunspell мало чем отличается (если вообще отличается) от других Shared Libraries.
Думаю, вы не совсем точно описали механизм.
Цитата:| Имя "libhunspell-1.7.so.0", которое вы видите намертво зашитым в бинарнике goldendict, - это не просто имя симссылки, оно берется из самого файла библиотеки. Когда libhunspell собирается, он (с помощью параметра -soname) говорит: я хочу называться "libhunspell-1.7.so.0" |
Но это и так понятно - о том то и речь. Собственно, в этом и заключается проблема.
Цитата:| Стандартная практика в таких случаях - выбирать soname вроде "libhunspell-1.so", чтобы всё не рушилось при малейшем обновлении. |
Кому выбирать?.. При сборке библиотеки? Либо системе при её установке? Либо при сборке программы её использующую?
На самом деле для этой цели и используется симлинк libhunspell.so. Никаких "libhunspell-1.so" среди установленных файлов/симлинков библиотек нет.
Цитата:| В процессе линковки GD открывается файл libhunspell.so, оттуда берётся его soname, зашивается в бинарник. |
Да, только линковка в бинарнике происходит на симлинк, на который (и только на который) указывает soname. И этот симлинк всегда специфичен для версии. Опять же, в этом и заключается проблема.
Цитата:| Думаю, проблему можно обойти, собирая со статической версией библиотеки (libhunspell.a, если она там есть). |
Такого файла нет. Проблему бы можно было бы обойти, если б линковка происходила на generic libhunspell.so, который, согласно содержимому PKGBUILD, создаётся так:
Код:| ln -s libhunspell-?.?.so libhunspell.so |
Т.е. версие-независим.
Хороший пост по теме.
Поэтому, ваше утверждение
Цитата:| Была бы. Проблема в hunspell. |
мне не совсем понятно. Это вполне стандартная ситуация для Shared Libraries.
И да, линковка на статический libhunspell.so в дефолтной конфигурации сборки, наверное, не лучший выход. Т.к. после обновления библиотеки, в какой-то момент совместимость может потеряться и стабильность программы будет под угрозой.
Но для частной конфигурации это вполне может быть выходом. В случае поломки/некорректной работы всегда можно будет пересобрать, уже со свежей версией hunspell.
Вопрос только в том, как при сборке залинковать именно на libhunspell.so, без привязки к специфической версии.
Другой варинат - это использовать ldconfig и /etc/ld.so.conf.d/ либо $LD_LIBRARY_PATH, чтоб "заморозить" конкретную версию либы, использовавшуюся во время сборки. Вручную это всё отностельно несложно сделать но как автоматизировать в PKGBUILD?...
Добавлено:
Svirepov
Продолжая размышлять... Или вы хотели сказать, что залинковать на libhunspell.so при сборке в принципе невозможно? Что в любом случае вернётся значение soname с соответствующим именем симлинка... Т.е. проблема не конкретно в hunspell, а вообще в механизме Shared Libraries в Linux.
-----
Возвращаясь к истокам  Как можно обойти проблему, чтоб после обновления библиотек GD не ломался? В идеале, сразу при сборке. Каким образом изменить PKGBUILD?
Или ну его нафиг - при обновлении hunspell просто создать симлинк с именем старой библиотеки, ведущий к libhunspell.so (который, в свою очередь залинкован всегда на новую)? |
Всего записей: 1329 | Зарегистр. 03-03-2008 | Отправлено: 12:00 27-12-2018 | Исправлено: Romul81, 12:22 27-12-2018 |
|
