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, тогда уже интереснее. Кстати, синхронизацию тоже не обязательно делать переносимой, а просто делать прегенерацию.