[devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

On Fri, Aug 11, 2006 at 11:42:54PM +0400, Alexey Tourbin wrote:
> On Fri, Aug 11, 2006 at 10:44:53PM +0400, Sergey Vlasov wrote:
> > Прошу высказать замечания по прилагаемому патчу, который добавляет
> > symbol versioning в libopenobex-1.3 (сейчас в Сизифе лежит 1.0.1).
[...]
> > Глубже версии 1.0.0 я копать не стал (это конец 2002 года, 1.0.1, где
> > не сделали ничего существенного - октябрь 2003).  На то, что было в
> > этих версиях, я поставил версию OPENOBEX_1.0 (можно было, конечно,
> > написать 1.0.0, но позднее формат версий немного сменился).
> > 
> > Функции OBEX_SetUserCallBack, OBEX_SetTransportMTU, OBEX_ServerAccept,
> > OBEX_ObjectReParseHeaders на самом деле были ещё в 1.0.0, но
> > фактически не были доступны из-за фильтрации символов по lib/obex.sym,
> > где они были пропущены (эта ошибка была исправлена уже после выхода
> > 1.0.1, и первый релиз, в который попало исправление - 1.1), поэтому я
> > поставил для этих символов версию OPENOBEX_1.1, как и для добавленных
> > позднее в ходе разработки 1.1 OBEX_SuspendRequest, OBEX_ResumeRequest,
> > OBEX_InterfaceConnect, OBEX_FindInterfaces, OBEX_FreeInterfaces.
> > После 1.1 вроде бы изменений ABI больше не было (во всяком случае,
> > файл lib/obex.sym больше не менялся).
> > 
> > Тест для autoconf самопальный - возможно, у кого-то есть варианты
> > лучше?
[...]
> Здесь вот что получается: "базовые" символы, у которых раньше интерфейса
> не было, теперь получат интерфейс по умолчанию OPENOBEX_1.0; и при
> линковке с этой библиотекой появится зависимость на OPENOBEX_1.0.  Это
> может быть не очень желательно, но может быть и нормально.

Но использованию старых бинарников, слинкованных ещё с libopenobex без
версий, в любом случае ничего мешать не будет?

Конечно, сейчас получится, что новые пакеты будут в любом случае
тащить за собой новую библиотеку, даже если на самом деле им хватает
ABI, предоставляемого версией 1.0 (т.е., полностью преимущества symbol
versioning проявятся только при расширении ABI в будущем).  Однако
предложенный ниже вариант мне нравится меньше...

> Я в таких случаях для базовых символов отдельного интерфейса не делаю,
> чтобы после добавления versioning при пересборке других пакетов не
> появлялось новых зависимостей.  Но приходится более тщательно
> контролировать секцию local: в первом блоке.
> 
> > +OPENOBEX_1.1 {
> > +global:
> > +
> > +	OBEX_FindInterfaces;
> > +	OBEX_FreeInterfaces;
> > +	OBEX_InterfaceConnect;
> > +	OBEX_ObjectReParseHeaders;
> > +	OBEX_ResumeRequest;
> > +	OBEX_ServerAccept;
> > +	OBEX_SetTransportMTU;
> > +	OBEX_SetUserCallBack;
> > +	OBEX_SuspendRequest;
> 
> Т.е. OPENOBEX_1.0 можно было не писать, а вот здесь вот (т.е.
> обязательно в первом блоке) написать секцию local: и перечислить все
> символы, которые не относятся к базовым.  Это можно сделать паттерном
> типа [^OIBF]*, но всё равно желательно каждый раз проверять, что там
> получается.  В общем тут есть свои мелкие преимущества и свои мелкие
> недостатки, я бы не рискнул дать однозначный совет.

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

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

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