[devel] Qt5 и поломанные плагины

[devel] Qt5 и поломанные плагины

[Vladimir D. Seleznev]

Доброго времени суток!

После вчерашнего обновления 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, то и не заметил бы поломки, пока кто-нибудь из пользователей не
пожаловался бы, т.е. отслеживание работоспособности плагинов остаётся на
пользователях.

Есть ли механизмы, с помощью которых можно было бы отслеживать подобные
поломки?  Если нет, то может у кого-нибудь есть идеи, как их можно было
бы отслеживать и добавить их в инфраструктуру сборочницы?

P.S. Стоит ли заботиться о возможности точечного обновления? Разумеется,
я могу сделать её в одну сторону, добавив requires на версию qt не
старше нужной, но опять-таки, она будет только в одну сторону.

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

Re: [devel] Qt5 и поломанные плагины

[Mikhail Efremov]

On Mon, 23 Oct 2017 14:49:15 +0300 Vladimir D. Seleznev wrote:
> Есть ли механизмы, с помощью которых можно было бы отслеживать
> подобные поломки?  Если нет, то может у кого-нибудь есть идеи, как их
> можно было бы отслеживать и добавить их в инфраструктуру сборочницы?

Ну, например, при сборке NM, чтобы убедиться, что плагинам хватает символов,
используется такой трюк:
LD_BIND_NOW=1 LD_PRELOAD=$${LD_PRELOAD}:$(1) $(builddir)/src/NetworkManager --version >/dev/null
где $(1) - плагин.
Но не знаю насколько возможно сделать такую проверку в общем случае, для
любых плагинов к любой программе.

-- 
WBR, Mikhail Efremov

Re: [devel] Qt5 и поломанные плагины

[Vladimir D. Seleznev]

On Mon, Oct 23, 2017 at 06:08:31PM +0300, Mikhail Efremov wrote:
> On Mon, 23 Oct 2017 14:49:15 +0300 Vladimir D. Seleznev wrote:
> > Есть ли механизмы, с помощью которых можно было бы отслеживать
> > подобные поломки?  Если нет, то может у кого-нибудь есть идеи, как их
> > можно было бы отслеживать и добавить их в инфраструктуру сборочницы?
>
> Ну, например, при сборке NM, чтобы убедиться, что плагинам хватает символов,
> используется такой трюк:
> LD_BIND_NOW=1 LD_PRELOAD=$${LD_PRELOAD}:$(1) $(builddir)/src/NetworkManager --version >/dev/null
> где $(1) - плагин.
> Но не знаю насколько возможно сделать такую проверку в общем случае, для
> любых плагинов к любой программе.

Я был не совсем прав: этот плагин слинкован с библиотеками Qt5, и он
падает при

$ ldd -r
/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so | grep symbol | head -n 3
symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file libQt5Gui.so.5 with link time reference (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so)
symbol _ZNK21QPlatformInputContext13hasCapabilityENS_10CapabilityE, version Qt_5 not defined in file libQt5Gui.so.5 with link time reference (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so)
symbol _ZN21QPlatformInputContext16staticMetaObjectE, version Qt_5 not defined in file libQt5Gui.so.5 with link time reference (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so)

это потому что некое множество символов сменило вершонинг с Qt_5 на
Qt_5_PRIVATE_API, при этом по setversion все зависимости остались
удовлетворёнными.

Из этого можно сделать печальное предположение, что сейчас в Сизифе
вероятно находится немало нерабочих Qt5-приложений.

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

Re: [devel] Qt5 и поломанные приложения

[Vladimir D. Seleznev]

On Mon, Oct 23, 2017 at 07:28:40PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Oct 23, 2017 at 06:08:31PM +0300, Mikhail Efremov wrote:
> > On Mon, 23 Oct 2017 14:49:15 +0300 Vladimir D. Seleznev wrote:
> > > Есть ли механизмы, с помощью которых можно было бы отслеживать
> > > подобные поломки?  Если нет, то может у кого-нибудь есть идеи, как их
> > > можно было бы отслеживать и добавить их в инфраструктуру сборочницы?
> >
> > Ну, например, при сборке NM, чтобы убедиться, что плагинам хватает символов,
> > используется такой трюк:
> > LD_BIND_NOW=1 LD_PRELOAD=$${LD_PRELOAD}:$(1) $(builddir)/src/NetworkManager --version >/dev/null
> > где $(1) - плагин.
> > Но не знаю насколько возможно сделать такую проверку в общем случае, для
> > любых плагинов к любой программе.
> 
> Я был не совсем прав: этот плагин слинкован с библиотеками Qt5, и он
> падает при
> 
> $ ldd -r
> /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so | grep symbol | head -n 3
> symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file libQt5Gui.so.5 with link time reference (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so)
> symbol _ZNK21QPlatformInputContext13hasCapabilityENS_10CapabilityE, version Qt_5 not defined in file libQt5Gui.so.5 with link time reference (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so)
> symbol _ZN21QPlatformInputContext16staticMetaObjectE, version Qt_5 not defined in file libQt5Gui.so.5 with link time reference (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so)
> 
> это потому что некое множество символов сменило вершонинг с Qt_5 на
> Qt_5_PRIVATE_API, при этом по setversion все зависимости остались
> удовлетворёнными.
> 
> Из этого можно сделать печальное предположение, что сейчас в Сизифе
> вероятно находится немало нерабочих Qt5-приложений.

Точнее, subj должен теперь быть такой.

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

Re: [devel] Qt5 и поломанные плагины

[Vitaly Lipatov]

Vladimir D. Seleznev писал 23.10.17 19:28:
...
> $ ldd -r
> /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
> | grep symbol | head -n 3
> symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file
> libQt5Gui.so.5 with link time reference
...
> 
> Из этого можно сделать печальное предположение, что сейчас в Сизифе
> вероятно находится немало нерабочих Qt5-приложений.
Достаточно ли проверить все плагины, размещённые в
/usr/lib64/qt5/plugins/ ?

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Qt5 и поломанные плагины

[Vladimir D. Seleznev]

On Mon, Oct 23, 2017 at 07:59:17PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 23.10.17 19:28:
> ...
> > $ ldd -r
> > /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
> > | grep symbol | head -n 3
> > symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file
> > libQt5Gui.so.5 with link time reference
> ...
> > 
> > Из этого можно сделать печальное предположение, что сейчас в Сизифе
> > вероятно находится немало нерабочих Qt5-приложений.
> Достаточно ли проверить все плагины, размещённые в
> /usr/lib64/qt5/plugins/ ?

Достаточно проверить все программы, библиотеки и плагины, слинкованные libqt5-*.

$ apt-cache search libqt5 | grep ^libqt5 | wc -l
63

А вот как проверить плагины, которые не слинкованы с libqt5-* — обшего
ответа у меня нет.

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

Re: [devel] Qt5 и поломанные плагины

[Vladimir D. Seleznev]

On Mon, Oct 23, 2017 at 08:07:23PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Oct 23, 2017 at 07:59:17PM +0300, Vitaly Lipatov wrote:
> > Vladimir D. Seleznev писал 23.10.17 19:28:
> > ...
> > > $ ldd -r
> > > /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
> > > | grep symbol | head -n 3
> > > symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file
> > > libQt5Gui.so.5 with link time reference
> > ...
> > > 
> > > Из этого можно сделать печальное предположение, что сейчас в Сизифе
> > > вероятно находится немало нерабочих Qt5-приложений.
> > Достаточно ли проверить все плагины, размещённые в
> > /usr/lib64/qt5/plugins/ ?
> 
> Достаточно проверить все программы, библиотеки и плагины, слинкованные libqt5-*.

Проверил несколько случайно выбранных приложений, слинкованных с
библиотеками Qt5 — не обнаружил никаких разъездов по символам. Видимо,
не всё так пессимистично, как я предполагал.

> $ apt-cache search libqt5 | grep ^libqt5 | wc -l
> 63
> 
> А вот как проверить плагины, которые не слинкованы с libqt5-* — обшего
> ответа у меня нет.

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

Re: [devel] Qt5 и поломанные плагины

[Vladimir D. Seleznev]

On Tue, Oct 24, 2017 at 12:08:07PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Oct 23, 2017 at 08:07:23PM +0300, Vladimir D. Seleznev wrote:
> > On Mon, Oct 23, 2017 at 07:59:17PM +0300, Vitaly Lipatov wrote:
> > > Vladimir D. Seleznev писал 23.10.17 19:28:
> > > ...
> > > > $ ldd -r
> > > > /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
> > > > | grep symbol | head -n 3
> > > > symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file
> > > > libQt5Gui.so.5 with link time reference
> > > ...
> > > > 
> > > > Из этого можно сделать печальное предположение, что сейчас в Сизифе
> > > > вероятно находится немало нерабочих Qt5-приложений.
> > > Достаточно ли проверить все плагины, размещённые в
> > > /usr/lib64/qt5/plugins/ ?
> > 
> > Достаточно проверить все программы, библиотеки и плагины, слинкованные libqt5-*.
> 
> Проверил несколько случайно выбранных приложений, слинкованных с
> библиотеками Qt5 — не обнаружил никаких разъездов по символам. Видимо,
> не всё так пессимистично, как я предполагал.

Поставил на поток автоматизированную проверку всех клиентов библиотек
Qt5, по результатам которой выяснилось, в результате смены versioning'а
некоторых символов пострадал только uim-qt5, т.е. остальные клиенты в
Сизифе остались работоспособными.

> > $ apt-cache search libqt5 | grep ^libqt5 | wc -l
> > 63
> > 
> > А вот как проверить плагины, которые не слинкованы с libqt5-* — обшего
> > ответа у меня нет.

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

Re: [devel] универсальный механизм проверки плагинов

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Mon, Oct 23, 2017 at 06:08:31PM +0300, Mikhail Efremov wrote:
> On Mon, 23 Oct 2017 14:49:15 +0300 Vladimir D. Seleznev wrote:
> > Есть ли механизмы, с помощью которых можно было бы отслеживать
> > подобные поломки?  Если нет, то может у кого-нибудь есть идеи, как их
> > можно было бы отслеживать и добавить их в инфраструктуру сборочницы?
> 
> Ну, например, при сборке NM, чтобы убедиться, что плагинам хватает символов,
> используется такой трюк:
> LD_BIND_NOW=1 LD_PRELOAD=$${LD_PRELOAD}:$(1) $(builddir)/src/NetworkManager --version >/dev/null
> где $(1) - плагин.
> Но не знаю насколько возможно сделать такую проверку в общем случае, для
> любых плагинов к любой программе.

У нас в rpm-build >= 4.0.4-alt100.91 есть механизм проверки плагинов,
который используется в разных пакетах.  Вот, например, я когда-то применил
его для irssi, выглядит это так (%_bindir/irssi можно прелоадить,
потому что он PIE):

export RPM_LD_PRELOAD_irssi=%buildroot%_bindir/irssi
export RPM_FILES_TO_LD_PRELOAD_irssi='%irssi_modules_dir/lib*.so %perl_vendor_autolib/Irssi/*.so'
export RPM_LD_PRELOAD_libperl_core='%buildroot%irssi_modules_dir/libperl_core.so'
export RPM_FILES_TO_LD_PRELOAD_libperl_core='%irssi_modules_dir/libfe_perl.so %perl_vendor_autolib/Irssi/*.so'
%set_verify_elf_method strict

Спрашивайте автора! :)


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] универсальный механизм проверки плагинов

[Михаил Радюк]

Зафиксировал в статье a.o./Spec

24 октября 2017 г., 3:51 пользователь Dmitry V. Levin
<ldv@altlinux.org> написал:
> On Mon, Oct 23, 2017 at 06:08:31PM +0300, Mikhail Efremov wrote:
>> On Mon, 23 Oct 2017 14:49:15 +0300 Vladimir D. Seleznev wrote:
>> > Есть ли механизмы, с помощью которых можно было бы отслеживать
>> > подобные поломки?  Если нет, то может у кого-нибудь есть идеи, как их
>> > можно было бы отслеживать и добавить их в инфраструктуру сборочницы?
>>
>> Ну, например, при сборке NM, чтобы убедиться, что плагинам хватает символов,
>> используется такой трюк:
>> LD_BIND_NOW=1 LD_PRELOAD=$${LD_PRELOAD}:$(1) $(builddir)/src/NetworkManager --version >/dev/null
>> где $(1) - плагин.
>> Но не знаю насколько возможно сделать такую проверку в общем случае, для
>> любых плагинов к любой программе.
>
> У нас в rpm-build >= 4.0.4-alt100.91 есть механизм проверки плагинов,
> который используется в разных пакетах.  Вот, например, я когда-то применил
> его для irssi, выглядит это так (%_bindir/irssi можно прелоадить,
> потому что он PIE):
>
> export RPM_LD_PRELOAD_irssi=%buildroot%_bindir/irssi
> export RPM_FILES_TO_LD_PRELOAD_irssi='%irssi_modules_dir/lib*.so %perl_vendor_autolib/Irssi/*.so'
> export RPM_LD_PRELOAD_libperl_core='%buildroot%irssi_modules_dir/libperl_core.so'
> export RPM_FILES_TO_LD_PRELOAD_libperl_core='%irssi_modules_dir/libfe_perl.so %perl_vendor_autolib/Irssi/*.so'
> %set_verify_elf_method strict
>
> Спрашивайте автора! :)
>
>
> --
> ldv
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
С уважением, Михаил.

Re: [devel] универсальный механизм проверки плагинов

[Vladimir D. Seleznev]

On Tue, Oct 24, 2017 at 03:51:56AM +0300, Dmitry V. Levin wrote:
> On Mon, Oct 23, 2017 at 06:08:31PM +0300, Mikhail Efremov wrote:
> > On Mon, 23 Oct 2017 14:49:15 +0300 Vladimir D. Seleznev wrote:
> > > Есть ли механизмы, с помощью которых можно было бы отслеживать
> > > подобные поломки?  Если нет, то может у кого-нибудь есть идеи, как их
> > > можно было бы отслеживать и добавить их в инфраструктуру сборочницы?
> > 
> > Ну, например, при сборке NM, чтобы убедиться, что плагинам хватает символов,
> > используется такой трюк:
> > LD_BIND_NOW=1 LD_PRELOAD=$${LD_PRELOAD}:$(1) $(builddir)/src/NetworkManager --version >/dev/null
> > где $(1) - плагин.
> > Но не знаю насколько возможно сделать такую проверку в общем случае, для
> > любых плагинов к любой программе.
> 
> У нас в rpm-build >= 4.0.4-alt100.91 есть механизм проверки плагинов,
> который используется в разных пакетах.  Вот, например, я когда-то применил
> его для irssi, выглядит это так (%_bindir/irssi можно прелоадить,
> потому что он PIE):
> 
> export RPM_LD_PRELOAD_irssi=%buildroot%_bindir/irssi
> export RPM_FILES_TO_LD_PRELOAD_irssi='%irssi_modules_dir/lib*.so %perl_vendor_autolib/Irssi/*.so'
> export RPM_LD_PRELOAD_libperl_core='%buildroot%irssi_modules_dir/libperl_core.so'
> export RPM_FILES_TO_LD_PRELOAD_libperl_core='%irssi_modules_dir/libfe_perl.so %perl_vendor_autolib/Irssi/*.so'
> %set_verify_elf_method strict
> 
> Спрашивайте автора! :)

Спасибо, но, увы, для случая uim-qt5 он не подходит.

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

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

Hi!

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 возрастёт не больше, чем в два 
раза. После перехода общая длина будет примерно такая же, как сейчас.

Володя, может быть, ты это уже пробовал реализовывать?

-- 
Best regards,
Ivan

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

[Alexey Tourbin]

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.  С наступающим!

Re: [devel] versioned set-versions

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Sat, Dec 30, 2017 at 06:51:42AM +0300, Alexey Tourbin wrote:
[...]
> Два механизма были сделаны ортогональными вовсе не по недомыслию, а и
> из-за сложной и компромиссной семантики разрешения версионированных
> символов.  Ясно, что неверсионированный символ может разрешаться в
> версионированный: sym -> sym@ABI, при условии, что символ sym@ABI
> дефолтный (так что когда в библиотеке впервые появляется
> версионирование, старые программы остаются работать без пересборки).

Более того, неверсионированный символ sym может разрешаться как в
неверсионированный символ, так и в версионированный sym@ABI без каких-либо
дополнительных условий; ld.so выберет из того, что есть в библиотеке,
какую-нибудь реализацию sym достаточно произвольным образом.  Если в
библиотеке окажется несколько реализаций sym разных версий, то ld.so
свяжет неверсионированный sym с одной из них.  Если в библиотеке, помимо
весрионированных sym, окажется и неверсионированная реализация, то ld.so
свяжет неверсионированный sym либо с неверсионированной реализацией, либо
с одной из версионированных.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Vladimir D. Seleznev]

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.  С наступающим!

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

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

[Alexey Tourbin]

2018-04-16 21:21 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> On Sat, Dec 30, 2017 at 06:51:42AM +0300, Alexey Tourbin wrote:
>> В данном случае разработчик как раз порезался своей опасной бритвой:
>> перенес символ из одного @ABI в другой, в результате чего ABI
>> изменился несовместимым образом. Разработчику надо повесить плакат над
>> рабочим местом: символ - это не бутерброд с колбасой, чтобы передавать
>> его из одного интерфейса в другой. Надо также отметить, что если бы
>> разработчик не делал вообще ничего, то проблемы бы не возникло.  (В
>> связи с этим возникают разные смешные вопросы: например, какова
>> производительность труда у этого разработчика?  Или же, выражаясь
>> словами Дреппера, можно ли подпускать его к клавиатуре?)
>>
>> Два механизма были сделаны ортогональными вовсе не по недомыслию, а и
>> из-за сложной и компромиссной семантики разрешения версионированных
>> символов.  Ясно, что неверсионированный символ может разрешаться в
>> версионированный: sym -> sym@ABI, при условии, что символ sym@ABI
>> дефолтный (так что когда в библиотеке впервые появляется
>> версионирование, старые программы остаются работать без пересборки).
>> Менее очевидно, что и версионированный символ можно разрешиться в
>> неверсионированный: sym@ABI -> sym, при условии, что @ABI существует
>> кое-где как самостоятельная единица, а символ sym неверсионированный
>> (такой компромисс требуется в частности для того, чтобы работало
>> переопределение функций через LD_PRELOAD).  Получается, что если мы
>> хотим требовать символ sym@ABI, то не понятно, что нам требовать:
>> требование sym@ABI оказывается достаточным, но не необходимым. То есть
>> мы суперимпозируем на ld.so какую-то более приятную нам логику
>> разрешения символов, чем она есть на самом деле.
>
> Поднимаю вопрос: согласны ли мы использовать более строгую логику
> разрешения символов, чем есть на самом деле?

Не согласны. :)
Критической массы выгоды мало, чтобы все переделывать и пересобирать,
а выгода будет - только обнаружение ситуаций sym@ABI1 != sym@ABI2,
каких только была одна за всю историю. Такие ситуации можно
обнаруживать и на уровне bad_elf_symbols.

>> Единственное разрешение, которое ld.so точно не допускает, это
>> sym@ABI1 -> sym@ABI2.
>>
>> Если все же накладывать на set-версии более приятную нам логику
>> разрешения символов, то можно было бы сделать следующее:
>>
>> 1) Требовать sym@ABI (требовать = хешировать как единый символ).
>> 2) Предоставлять два символа: sym@ABI и sym (кроме недефолтных
>> симолов, для которых предоставлять только sym@ABI).

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

[Vladimir D. Seleznev]

On Fri, Dec 29, 2017 at 04:38:38PM +0300, Ivan Zakharyaschev wrote:
> Hi!
> 
> 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 возрастёт не больше, чем в два 
> раза. После перехода общая длина будет примерно такая же, как сейчас.
> 
> Володя, может быть, ты это уже пробовал реализовывать?

Пока нет, я думал посмотреть на это в январские праздники.

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