Shared Library Symbol Versioning HOWTO: различия между версиями
Нет описания правки |
Нет описания правки |
||
| (не показана 1 промежуточная версия 1 участника) | |||
| Строка 1: | Строка 1: | ||
{{Stub}} | {{Stub}} | ||
| Строка 6: | Строка 5: | ||
=== Поведение апстрима === | === Поведение апстрима === | ||
# '''Апстрим не отвечает за бинарную совместимость.''' Это особенно плохо вот в каком отношении: бинарная совместимость может обеспечивается не только названиями функций и переменных, но ещё и доступом к полям структур (например, структура может целиком создаваться на стеке). В Си доступ к полям структуры | # '''Апстрим не отвечает за бинарную совместимость.''' Это особенно плохо вот в каком отношении: бинарная совместимость может обеспечивается не только названиями функций и переменных, но ещё и доступом к полям структур (например, структура может целиком создаваться на стеке). В Си доступ к полям структуры заменяется на доступ по смещению относительно начального адреса размещения структуры (то есть поля структуры на самом деле «пронумерованы» примерно как в массиве). Это означает, что (если API подразумевает доступ к полям структур) если просто переставить местами два поля в структуре, то вся бинарная совместимость накрывается медным тазом. При таком раскладе следить за бинарной совместимостью очень сложно. Version script может не помочь, нужно дополнительно изучать хедеры на предмет прототипов и структур. И тогда либо самому менять сонейм, если он вообще есть, либо, другой вариант — просто собирать библиотеку статически и линковаться с ней статически. | ||
# '''Апстрим понимает, что такое бинарная совместимость, и не делает глупостей''' (по крайней мере, не меняет базовых определений и прототипов). К счастью, такой расклад имеет место быть с большей частью системных библиотек. Тогда достаточно убедиться, что: | # '''Апстрим понимает, что такое бинарная совместимость, и не делает глупостей''' (по крайней мере, не меняет базовых определений и прототипов). К счастью, такой расклад имеет место быть с большей частью системных библиотек. Тогда достаточно убедиться, что: | ||
## В новой версии библиотеки не исчезли никакие старые переменные, и, по крайней мере, функции. Если исчезли, тогда нужно проверить, что их никто не использует. Если их кто-то использует, тогда придётся восстанавливать. | ## В новой версии библиотеки не исчезли никакие старые переменные, и, по крайней мере, функции. Если исчезли, тогда нужно проверить, что их никто не использует. Если их кто-то использует, тогда придётся восстанавливать. | ||
## Если добавились новые переменные или функции, сделать version script (добавить новую секцию в version script, в которой перечислены все новые переменные и, по крайней мере, функции). | ## Если добавились новые переменные или функции, сделать version script (добавить новую секцию в version script, в которой перечислены все новые переменные и, по крайней мере, функции). | ||
=== Как проверить, что убавившиеся функции никто не использует === | === Как проверить, что убавившиеся функции никто не использует === | ||
| Строка 20: | Строка 18: | ||
Нужно собрать новую версию пакета в тестовом режиме (со старым version script или без него). Далее установить пакет <tt>qa-robot</tt> и запустить '<tt>rpmsodiff libстарый.rpm libновый.rpm</tt>'. Он покажет, какие символы убавились, а какие добавились, а также выдаст заготовку для version script’а. Эту заготовку нужно поместить в файл с названием <tt>lib%name.map</tt> (альтернативно <tt>lib%name.ver</tt>, <tt>lib%name.sym</tt> или <tt>lib%name.def</tt>), возможно, немножко поправив название секции (<tt>LIBNAME_1.2.3</tt> vs <tt>NAME_1.2.3</tt>). Этот файл далее нужно скормить в <tt>gcc</tt> или <tt>libtool</tt> с помощью <tt>-Wl,--version-script=lib%name.def</tt>. Убедиться, что у пакета появился provides вида <tt>lib%name*.so*(LIBNAME_1.2.3)</tt>. | Нужно собрать новую версию пакета в тестовом режиме (со старым version script или без него). Далее установить пакет <tt>qa-robot</tt> и запустить '<tt>rpmsodiff libстарый.rpm libновый.rpm</tt>'. Он покажет, какие символы убавились, а какие добавились, а также выдаст заготовку для version script’а. Эту заготовку нужно поместить в файл с названием <tt>lib%name.map</tt> (альтернативно <tt>lib%name.ver</tt>, <tt>lib%name.sym</tt> или <tt>lib%name.def</tt>), возможно, немножко поправив название секции (<tt>LIBNAME_1.2.3</tt> vs <tt>NAME_1.2.3</tt>). Этот файл далее нужно скормить в <tt>gcc</tt> или <tt>libtool</tt> с помощью <tt>-Wl,--version-script=lib%name.def</tt>. Убедиться, что у пакета появился provides вида <tt>lib%name*.so*(LIBNAME_1.2.3)</tt>. | ||
{{Category navigation|title=HOWTO|category=HOWTO|sortkey={{SUBPAGENAME}}}} | |||
Текущая версия от 15:21, 19 июля 2015
рассказать что такое symbol versioning и зачем он нужен
Поведение апстрима
- Апстрим не отвечает за бинарную совместимость. Это особенно плохо вот в каком отношении: бинарная совместимость может обеспечивается не только названиями функций и переменных, но ещё и доступом к полям структур (например, структура может целиком создаваться на стеке). В Си доступ к полям структуры заменяется на доступ по смещению относительно начального адреса размещения структуры (то есть поля структуры на самом деле «пронумерованы» примерно как в массиве). Это означает, что (если API подразумевает доступ к полям структур) если просто переставить местами два поля в структуре, то вся бинарная совместимость накрывается медным тазом. При таком раскладе следить за бинарной совместимостью очень сложно. Version script может не помочь, нужно дополнительно изучать хедеры на предмет прототипов и структур. И тогда либо самому менять сонейм, если он вообще есть, либо, другой вариант — просто собирать библиотеку статически и линковаться с ней статически.
- Апстрим понимает, что такое бинарная совместимость, и не делает глупостей (по крайней мере, не меняет базовых определений и прототипов). К счастью, такой расклад имеет место быть с большей частью системных библиотек. Тогда достаточно убедиться, что:
- В новой версии библиотеки не исчезли никакие старые переменные, и, по крайней мере, функции. Если исчезли, тогда нужно проверить, что их никто не использует. Если их кто-то использует, тогда придётся восстанавливать.
- Если добавились новые переменные или функции, сделать version script (добавить новую секцию в version script, в которой перечислены все новые переменные и, по крайней мере, функции).
Как проверить, что убавившиеся функции никто не использует
Нужно иметь копию Сизифа. Нужно установить пакет qa-robot и запустить 'qa-robot bad_elf_symbols /ALT/Sisyphus/files/i586/RPMS'. Далее грепать файл ~/.qa-robot/bad_elf_symbols/ref на предмет убавившихся символов.
Как узнать, убавились ли или добавились новые символы и как сделать version script
Нужно собрать новую версию пакета в тестовом режиме (со старым version script или без него). Далее установить пакет qa-robot и запустить 'rpmsodiff libстарый.rpm libновый.rpm'. Он покажет, какие символы убавились, а какие добавились, а также выдаст заготовку для version script’а. Эту заготовку нужно поместить в файл с названием lib%name.map (альтернативно lib%name.ver, lib%name.sym или lib%name.def), возможно, немножко поправив название секции (LIBNAME_1.2.3 vs NAME_1.2.3). Этот файл далее нужно скормить в gcc или libtool с помощью -Wl,--version-script=lib%name.def. Убедиться, что у пакета появился provides вида lib%name*.so*(LIBNAME_1.2.3).