[devel] versioned set-versions; was: Re: Qt5 и поломанные плагины
Alexey Tourbin
alexey.tourbin на gmail.com
Сб Апр 21 00:45:04 MSK 2018
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).
Подробная информация о списке рассылки Devel