[devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

On Sat, Aug 12, 2006 at 02:43:52PM +0400, Sergey Vlasov wrote:
> > Здесь вот что получается: "базовые" символы, у которых раньше интерфейса
> > не было, теперь получат интерфейс по умолчанию OPENOBEX_1.0; и при
> > линковке с этой библиотекой появится зависимость на OPENOBEX_1.0.  Это
> > может быть не очень желательно, но может быть и нормально.
> 
> Но использованию старых бинарников, слинкованных ещё с libopenobex без
> версий, в любом случае ничего мешать не будет?

Да.  Требуемый символ без версии разрешается в предоставляемый символ по
умолчанию; последний может быть и с версией (readelf -s рисует такие
символы с двумя собаками @@).

> В данном случае upstream уже использует ограничение набора
> экспортируемых из библиотеки символов средствами libtool
> (-export-symbols obex.sym, в файле obex.sym находится список символов,
> образующих ABI библиотеки).  Хотелось бы, чтобы старый и новый способы
> всегда давали одинаковый набор доступных символов.  В случае
> использования [^OIBF]* это условие может не выполняться, например,
> если в библиотеку добавили новую функцию, но забыли обновить файлы со
> списком символов.  Такая функция при использовании -export-symbols
> obex.sym, где содержится явный список всех символов, просто не будет
> доступна, что не повлияет на ранее собранные программы, но немедленно
> обнаружится при сборке новых программ, использующих эту функцию, и
> может быть исправлено без необходимости пересборки всего, что
> использует эту библиотеку; то же самое произойдёт и при использовании
> obex.ver с явным указанием всех символов.  В случае же, если все
> символы вида OBEX_* по умолчанию попадают в библиотеку без
> присваивания версии, подобная ошибка может долгое время оставаться
> незамеченной, а её исправление потребует пересборки всего, что было
> слинковано с библиотекой (чтобы получить правильные зависимости на
> версии).

Однако синхронизация между obex.sym и obex.map (version script), вообще
говоря, ничем не гарантирована.  Это значит, что возможна
рассинхронизация как в сторону лишних экспортируемых символов
в библиотеке, так и в сторону отсутствия необходимых символов.

Насколько лучше рисковать недоэкспортом, чем переэкспортом?  Вопрос
тонкий, и я думаю, что однозначного ответа нет.  При жестком подходе --
запрещено всё, что не разрешено -- ошибка недоэкспорта может и не
обнаружиться, если клиент библиотеки использует AC_TRY_LINK.  Более
мягкий подход у меня ассоциируется с принципом "не навреди".  А именно,
чего мы хотим добиться? -- мы хотим добавить symbol versioning.  Что
может произойти в худшем случае? -- символы не отслеживаются и
versioning работает лишь частично.  То есть при мягком подходе мы более
или менее добиваемся поставленной цели.  А при жестком подходе в худшем
случае мы получаем вредный side effect -- символы экспортируются не
полностью.  Это совсем не то, за что мы боролись.

Однако и мягкий, и жесткий подход в случае известной аккуратности должны
давать эквивалентный результат.  За вычетом появления интерфейса по
умолчанию.

> Можно было бы попытаться при отсутствии полного списка символов в
> obex.ver как-то сравнивать результат сборки с содержимым файла
> obex.sym, чтобы обнаружить лишние символы, но не уверен, что это можно
> сделать переносимым способом, пригодным для upstream.

Для апстрима достаточно иметь непереносимый способ, который работает
у девелоперов на заранее известной архитектуре.  Ибо после релиза
сравнивать уже смысла нет.

> Кстати, при использовании явного списка можно будет попробовать
> сделать obex.ver основным файлом, а obex.sym генерировать из него,
> например, с помощью sed (но в этом случае придётся наложить на формат
> obex.ver дополнительные ограничения).

А!  Если обеспечить синхронизацию ver и sym, тогда уже интереснее.
Кстати, синхронизацию тоже не обязательно делать переносимой, а просто
делать прегенерацию.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20060812/d7b8f61d/attachment-0001.bin>