[devel] versioned set-versions; was: Re: Qt5 и поломанные плагины

Пн Апр 16 21:21:00 MSK 2018

On Sat, Dec 30, 2017 at 06:51:42AM +0300, Alexey Tourbin wrote:
> 2017-12-29 16:38 GMT+03:00 Ivan Zakharyaschev <imz на altlinux.org>:
> > On Mon, 23 Oct 2017, Vladimir D. Seleznev wrote:
> >> После вчерашнего обновления Qt5 сломалась работоспособность uim-qt5,
> >> который должен был работать как плагин к Qt5, но с новым релизом
> >> последнего не подключается с такой диагностикой:
> >>
> >> Got keys from plugin meta data ("uim")
> >> QFactoryLoader::QFactoryLoader() checking directory path
> >> "/usr/bin/platforminputcontexts" ...
> >> Cannot load library
> >> /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
> >>
> >> (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
> >> symbol _ZTI21QPlatformInputContext,
> >> version Qt_5 not defined in file libQt5Gui.so.5 with link time reference)
> >> QLibraryPrivate::loadPlugin failed on
> >>
> >> "/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so"
> >> : "Cannot load library
> >>
> >> /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
> >>
> >> (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
> >> symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file
> >> libQt5Gui.so.5 with link time reference)"
> >>
> >> По setversion всё в порядке, но видно, что символ
> >> _ZTI21QPlatformInputContext в libQt5Gui.so.5 переехал с Qt_5 на
> >> Qt_5_PRIVATE_API.
> >>
> >> Это чинится пересборкой uim'а с новым Qt5, но если бы я не использовал
> >> uim-qt5, то и не заметил бы поломки, пока кто-нибудь из пользователей не
> >> пожаловался бы, т.е. отслеживание работоспособности плагинов остаётся на
> >> пользователях.
> >>
> >> Есть ли механизмы, с помощью которых можно было бы отслеживать подобные
> >> поломки?  Если нет, то может у кого-нибудь есть идеи, как их можно было
> >> бы отслеживать и добавить их в инфраструктуру сборочницы?
> >
> > Вспомнилось, что мы думали о разделении set на несколько множеств -- по
> > версионированию. (Раз мы версионированию upstream-ов вообще не доверяем и
> > имеем механизм set-versions.)
> >
> > Следов того обсуждения я сходу не нашёл.
> >
> > Отдельно требовалось продумать переходный период. Иметь Provides и со всем
> > суммарным множеством (как сейчас), и разделённые. В случае наличия
> > разделённых, генерировать Requires на разделённые.
> >
> > Во время перехода длина затронутых Provides возрастёт не больше, чем в два
> > раза. После перехода общая длина будет примерно такая же, как сейчас.
> 
> Когда делались set-версии, я мыслил большей часть в терминах
> наличия/отсутствия нужных функций; то есть это было улучшенное решение
> проблемы "минимальной версии": найти минимальную версию библиотеки, в
> которой все нужные функции предоставляются (улучшенное = с защитой от
> удаления в последующих версиях).  Версионирование @ABI - это более
> сложный, тонкий и опасный механизм.  Если разработчик его использует,
> то он должен знать, что он делает.  Set-версии и версионирование @ABI
> получились ортогональными механизмами: они никак друг другу не мешают
> и вообще не интерферируют.
> 
> В данном случае разработчик как раз порезался своей опасной бритвой:
> перенес символ из одного @ABI в другой, в результате чего ABI
> изменился несовместимым образом. Разработчику надо повесить плакат над
> рабочим местом: символ - это не бутерброд с колбасой, чтобы передавать
> его из одного интерфейса в другой. Надо также отметить, что если бы
> разработчик не делал вообще ничего, то проблемы бы не возникло.  (В
> связи с этим возникают разные смешные вопросы: например, какова
> производительность труда у этого разработчика?  Или же, выражаясь
> словами Дреппера, можно ли подпускать его к клавиатуре?)
> 
> Два механизма были сделаны ортогональными вовсе не по недомыслию, а и
> из-за сложной и компромиссной семантики разрешения версионированных
> символов.  Ясно, что неверсионированный символ может разрешаться в
> версионированный: sym -> sym на ABI, при условии, что символ sym на ABI
> дефолтный (так что когда в библиотеке впервые появляется
> версионирование, старые программы остаются работать без пересборки).
> Менее очевидно, что и версионированный символ можно разрешиться в
> неверсионированный: sym на ABI -> sym, при условии, что @ABI существует
> кое-где как самостоятельная единица, а символ sym неверсионированный
> (такой компромисс требуется в частности для того, чтобы работало
> переопределение функций через LD_PRELOAD).  Получается, что если мы
> хотим требовать символ sym на ABI, то не понятно, что нам требовать:
> требование sym на ABI оказывается достаточным, но не необходимым. То есть
> мы суперимпозируем на ld.so какую-то более приятную нам логику
> разрешения символов, чем она есть на самом деле.

Поднимаю вопрос: согласны ли мы использовать более строгую логику
разрешения символов, чем есть на самом деле?

> Единственное разрешение, которое ld.so точно не допускает, это
> sym на ABI1 -> sym на ABI2.
> 
> Если все же накладывать на set-версии более приятную нам логику
> разрешения символов, то можно было бы сделать следующее:
> 
> 1) Требовать sym на ABI (требовать = хешировать как единый символ).
> 2) Предоставлять два символа: sym на ABI и sym (кроме недефолтных
> симолов, для которых предоставлять только sym на ABI).
> 
> В еще более общем виде символы можно было бы хешировать как
> sym(args)@ABI, поскольку сигнатуру функции можно узнать из DWARF (из
> отладочной информации -g).  Тогда еще и получится защита от изменения
> количества и типа аргументов. Об этом был мой доклад
> https://github.com/svpv/protva2016/blob/master/protva2016.pdf
> Временами я порываюсь этим заняться, но здесь есть слишком большой
> нетехнический аспект.  Понимаете, когда у людей вроде вашего
> руководства наконец-то появляются деньги, то они ставят это в заслугу
> себе, а к другим относятся разве что снисходительнее. Туго набитые
> карманы делают неинтересным вопрос об истинном положении вещей.
> Впрочем, истинное положение вещей знает только Господ Бог, а ему до
> нас кажется дела нету. Так что, как говорится, everyone must fend for
> himself.  С наступающим!

-- 
   С уважением,
   Владимир Селезнев