[devel] [RFC] libopenobex-1.3 symbol versioning patch

[devel] [RFC] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 5094 bytes --]

Hello!

Прошу высказать замечания по прилагаемому патчу, который добавляет
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.3/lib/Makefile.am.alt-symbol-versions	2006-08-11 16:38:36 +0400
+++ openobex-1.3/lib/Makefile.am	2006-08-11 22:05:23 +0400
@@ -17,14 +17,20 @@ libopenobex_la_SOURCES = \
 	irda.h irda_wrap.h \
 	usbobex.c usbobex.h
 
+if VERSIONED_SYMBOLS
+VSYMS = -Wl,--version-script=$(srcdir)/obex.ver
+else
+VSYMS = -export-symbols $(srcdir)/obex.sym
+endif
+
 libopenobex_la_LDFLAGS = \
 	-version-info 4:0:3 \
-	-export-symbols $(top_srcdir)/lib/obex.sym
+	$(VSYMS)
 
 libopenobex_la_LIBADD = @USB_LIBS@
 
 INCLUDES = -I$(top_builddir)/include
 
-EXTRA_DIST = obex.sym win32compat.c
+EXTRA_DIST = obex.ver obex.sym win32compat.c
 
 MAINTAINERCLEANFILES = Makefile.in
--- openobex-1.3/lib/obex.ver.alt-symbol-versions	2006-08-11 22:05:23 +0400
+++ openobex-1.3/lib/obex.ver	2006-08-11 22:05:23 +0400
@@ -0,0 +1,57 @@
+OPENOBEX_1.0 {
+global:
+
+	OBEX_Init;
+	OBEX_Cleanup;
+	OBEX_RegisterCTransport;
+	OBEX_SetCustomData;
+	OBEX_GetCustomData;
+	OBEX_TransportConnect;
+	OBEX_TransportDisconnect;
+	OBEX_CustomDataFeed;
+	OBEX_GetFD;
+	OBEX_HandleInput;
+	OBEX_ServerRegister;
+	OBEX_Request;
+	OBEX_CancelRequest;
+	OBEX_SetUserData;
+	OBEX_GetUserData;
+	OBEX_ObjectNew;
+	OBEX_ObjectDelete;
+	OBEX_ObjectAddHeader;
+	OBEX_ObjectGetNextHeader;
+	OBEX_ObjectReadStream;
+	OBEX_ObjectSetRsp;
+	OBEX_ObjectGetNonHdrData;
+	OBEX_ObjectSetNonHdrData;
+	OBEX_ObjectSetHdrOffset;
+	OBEX_UnicodeToChar;
+	OBEX_CharToUnicode;
+	OBEX_ResponseToString;
+	OBEX_GetResponseMessage;
+	InOBEX_ServerRegister;
+	InOBEX_TransportConnect;
+	IrOBEX_ServerRegister;
+	IrOBEX_TransportConnect;
+	BtOBEX_ServerRegister;
+	BtOBEX_TransportConnect;
+	FdOBEX_TransportSetup;
+
+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;
--- openobex-1.3/acinclude.m4.alt-symbol-versions	2006-08-11 16:38:36 +0400
+++ openobex-1.3/acinclude.m4	2006-08-11 22:12:09 +0400
@@ -44,6 +44,55 @@ AC_DEFUN([AC_INIT_OPENOBEX], [
 	AC_DEFINE_UNQUOTED(CONFIGDIR, "${configdir}", [Directory for the configuration files])
 ])
 
+AC_DEFUN([AC_CHECK_VERSIONED_SYMBOLS], [
+	AC_ARG_ENABLE(symbol-versions,
+	  AC_HELP_STRING([--disable-symbol-versions], [do not compile shared library with versioned symbols]),
+	  versioned="$withval", versioned="yes")
+	if test "$versioned" = "yes"; then
+	  AC_CACHE_CHECK([whether -Wl,--version-script=... works], ac_cv_version_script_works, [
+	  	cat <<ACEOF >conftest.ver
+TEST_1.0 {
+global:
+	test_1_0;
+local:
+	*;
+};
+TEST_1.1 {
+global:
+	test_1_1;
+} TEST_1.0;
+ACEOF
+	  	saved_LDFLAGS="$LDFLAGS"
+		LDFLAGS="$LDFLAGS -shared -Wl,--version-script=conftest.ver"
+		AC_TRY_LINK([
+				int test_1_0(void)
+				{
+					return 0;
+				}
+				int test_1_1(void)
+				{
+					return 1;
+				}
+			], [],
+			[ac_cv_version_script_works=yes],
+			[ac_cv_version_script_works=no])
+	  	LDFLAGS="$saved_LDFLAGS"
+	  ])
+	  if test "$ac_cv_version_script_works" = "yes"; then
+	  	:
+	  else
+	  	versioned=no
+	  fi
+	fi
+	AC_MSG_CHECKING(for versioned symbols)
+	if test "$versioned" = "yes"; then
+		AC_MSG_RESULT(yes)
+	else
+		AC_MSG_RESULT(no)
+	fi
+	AM_CONDITIONAL(VERSIONED_SYMBOLS, test x$versioned = xyes)
+])
+
 AC_DEFUN([AC_PATH_IRDA], [
 	AC_CACHE_CHECK([for IrDA support], irda_found, [
 		AC_TRY_COMPILE([
--- openobex-1.3/configure.in.alt-symbol-versions	2006-08-11 16:38:36 +0400
+++ openobex-1.3/configure.in	2006-08-11 22:05:23 +0400
@@ -18,6 +18,7 @@ m4_define([_LT_AC_TAGCONFIG], [])
 m4_ifdef([AC_LIBTOOL_TAGS], [AC_LIBTOOL_TAGS([])])
 
 AC_PROG_LIBTOOL
+AC_CHECK_VERSIONED_SYMBOLS
 
 AC_PATH_IRDA
 AC_PATH_BLUEZ


-- 
Sergey Vlasov

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3904 bytes --]

On Fri, Aug 11, 2006 at 10:44:53PM +0400, Sergey Vlasov wrote:
> Hello!
> 
> Прошу высказать замечания по прилагаемому патчу, который добавляет
> symbol versioning в libopenobex-1.3 (сейчас в Сизифе лежит 1.0.1).

[ Перепутал сначала с openbox:

А что, кто-то ещё линкуется с libopenbox, кроме самого openbox?
В apt-cache пока не видно.

Теперь посмотрел внимательнее и вижу, что не openbox. ]

> Глубже версии 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.3/lib/obex.ver.alt-symbol-versions	2006-08-11 22:05:23 +0400
> +++ openobex-1.3/lib/obex.ver	2006-08-11 22:05:23 +0400
> @@ -0,0 +1,57 @@
> +OPENOBEX_1.0 {
> +global:
> +
> +	OBEX_Init;
> +	OBEX_Cleanup;
> +	OBEX_RegisterCTransport;
> +	OBEX_SetCustomData;
> +	OBEX_GetCustomData;
> +	OBEX_TransportConnect;
> +	OBEX_TransportDisconnect;
> +	OBEX_CustomDataFeed;
> +	OBEX_GetFD;
> +	OBEX_HandleInput;
> +	OBEX_ServerRegister;
> +	OBEX_Request;
> +	OBEX_CancelRequest;
> +	OBEX_SetUserData;
> +	OBEX_GetUserData;
> +	OBEX_ObjectNew;
> +	OBEX_ObjectDelete;
> +	OBEX_ObjectAddHeader;
> +	OBEX_ObjectGetNextHeader;
> +	OBEX_ObjectReadStream;
> +	OBEX_ObjectSetRsp;
> +	OBEX_ObjectGetNonHdrData;
> +	OBEX_ObjectSetNonHdrData;
> +	OBEX_ObjectSetHdrOffset;
> +	OBEX_UnicodeToChar;
> +	OBEX_CharToUnicode;
> +	OBEX_ResponseToString;
> +	OBEX_GetResponseMessage;
> +	InOBEX_ServerRegister;
> +	InOBEX_TransportConnect;
> +	IrOBEX_ServerRegister;
> +	IrOBEX_TransportConnect;
> +	BtOBEX_ServerRegister;
> +	BtOBEX_TransportConnect;
> +	FdOBEX_TransportSetup;
> +
> +local:
> +	*;
> +};

Здесь вот что получается: "базовые" символы, у которых раньше интерфейса
не было, теперь получат интерфейс по умолчанию OPENOBEX_1.0; и при
линковке с этой библиотекой появится зависимость на OPENOBEX_1.0.  Это
может быть не очень желательно, но может быть и нормально.

Я в таких случаях для базовых символов отдельного интерфейса не делаю,
чтобы после добавления 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]*, но всё равно желательно каждый раз проверять, что там
получается.  В общем тут есть свои мелкие преимущества и свои мелкие
недостатки, я бы не рискнул дать однозначный совет.

> +} OPENOBEX_1.0;

Кстати список можно проверить с помощью rpmsodiff из пакета qa-robot.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 4802 bytes --]

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 дополнительные ограничения).

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3917 bytes --]

On Sat, Aug 12, 2006 at 03:19:10PM +0400, Alexey Tourbin wrote:
> Однако синхронизация между obex.sym и obex.map (version script), вообще
> говоря, ничем не гарантирована.  Это значит, что возможна
> рассинхронизация как в сторону лишних экспортируемых символов
> в библиотеке, так и в сторону отсутствия необходимых символов.

Эта проблема устраняется автогенерацией - либо obex.sym из obex.ver
(возможно только в случае наличия полного списка символов в obex.ver),
либо и obex.sym, и obex.ver из какого-то файла с простым и удобным для
этого форматом (в этом случае в принципе можно сделать и вариант без
прописывания версии для "старых" символов).

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

В данном случае upstream уже использует жёсткий подход - символы, не
добавленные в obex.sym, оказываются недоступными.  В этом случае
применение для obex.ver мягкого подхода приведёт к возможности
появления платформозависимых ошибок - в системах, не поддерживающих
-Wl,--version-script, но при этом поддерживающих -export-symbols через
libtool, пропущенные символы будут недоступны, в то время как в
системах, поддерживающих -Wl,--version-script, такие символы останутся
доступными.  Вряд ли upstream согласится на такое.

Кстати, а обязан ли каждому паттерну в local соответствовать хотя бы
один реально существующий символ?  Если нет, можно попробовать
сгенерировать что-то такого типа:

local:
	[^BFIO]*;
	O[^B]*;
	OB[^E]*;
	OBE[^X]*;
	OBEX[^_]*;
	OBEX_[^....]*;
	...
	OBEX_TransportDisconnec[^t]*;
	OBEX_TransportDisconnect?*;
	...

Хотя как бы с такими паттернами не напороться на баги в каком-нибудь
кривом сановском линкере (или там опции всё равно другие?), или старых
binutils.

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

Вопрос в том, как проще и надёжнее сделать аккуратность обязательной.

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

Если эту проверку нельзя засунуть в Makefile.am, чтобы она выполнялась
всегда, скорее всего, запускать её никто никогда не будет.

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

Да, можно (например, это стандартный способ использования lex/yacc -
обычно в релиз кладут уже сгенерированные файлы; хотя в данном случае
проблема скорее не в переносимости, а в сборочных зависимостях).

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]

On Sat, Aug 12, 2006 at 05:00:37PM +0400, Sergey Vlasov wrote:
> > Насколько лучше рисковать недоэкспортом, чем переэкспортом?  Вопрос
> > тонкий, и я думаю, что однозначного ответа нет.  При жестком подходе --
> > запрещено всё, что не разрешено -- ошибка недоэкспорта может и не
> > обнаружиться, если клиент библиотеки использует AC_TRY_LINK.  Более
> > мягкий подход у меня ассоциируется с принципом "не навреди".  А именно,
> > чего мы хотим добиться? -- мы хотим добавить symbol versioning.  Что
> > может произойти в худшем случае? -- символы не отслеживаются и
> > versioning работает лишь частично.  То есть при мягком подходе мы более
> > или менее добиваемся поставленной цели.  А при жестком подходе в худшем
> > случае мы получаем вредный side effect -- символы экспортируются не
> > полностью.  Это совсем не то, за что мы боролись.
> 
> В данном случае upstream уже использует жёсткий подход - символы, не
> добавленные в obex.sym, оказываются недоступными.  В этом случае
> применение для obex.ver мягкого подхода приведёт к возможности
> появления платформозависимых ошибок - в системах, не поддерживающих
> -Wl,--version-script, но при этом поддерживающих -export-symbols через
> libtool, пропущенные символы будут недоступны, в то время как в
> системах, поддерживающих -Wl,--version-script, такие символы останутся
> доступными.  Вряд ли upstream согласится на такое.

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

Но если у пакета казуальный maintainer, которому version script дали
в долг, тем более если в апстриме не используется -export-symbols,
тогда вряд стоит делать эту карту эксклюзивной.

> Кстати, а обязан ли каждому паттерну в local соответствовать хотя бы
> один реально существующий символ?

Кстати, и в списке global каждому элементу в общем-то не обязан
соответствовать какой-либо реально существующий символ (сюрприз!).
Филькина грамота этот version script в общем.

> Если нет, можно попробовать
> сгенерировать что-то такого типа:
> 
> local:
> 	[^BFIO]*;
> 	O[^B]*;
> 	OB[^E]*;
> 	OBE[^X]*;
> 	OBEX[^_]*;
> 	OBEX_[^....]*;
> 	...
> 	OBEX_TransportDisconnec[^t]*;
> 	OBEX_TransportDisconnect?*;
> 	...
> 
> Хотя как бы с такими паттернами не напороться на баги в каком-нибудь
> кривом сановском линкере (или там опции всё равно другие?), или старых
> binutils.

В каком смысле сгенерировать?  Идея интересная, но при наличии на руках
объектного материала можно генерировать не паттерны, а уже сами символы.

Кстати, интересная идея мне в голову пришла: в libtool нужно добавить
новую опцию: --version-script (похожую на --export-symbols).  Тогда на
платформах, которые не поддерживают versioning, libtool смог бы
схлопывать карту verion script в список export symbols.  В случае, если
список эксклюзивный и все символы явно перечислены, тогда вообще всё
просто и это дается чем-то вроде

perl -lne '/^\s+(\w+);/&&print$1'

или то же самое на sed'е, хотя перл кажется более портабельный чем sed.
Но в общем виде конечно нужен парсер и работа с объектным материалом, а
это с этим уже больше сложностей.  Но в принципе это должно делаться
где-то на уровне libtool.  На то он и libtool.

Либтул ведь сейчас генерирует из списка карту, что конечно же не фокус.
А вот обратно ему пока слабо.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Sat, Aug 12, 2006 at 05:32:57PM +0400, Alexey Tourbin wrote:
> Но в общем виде конечно нужен парсер и работа с объектным материалом, а
> это с этим уже больше сложностей.  Но в принципе это должно делаться
> где-то на уровне libtool.  На то он и libtool.

Кстати либтул уже работает с объектным материалом, когда генерирует
карту по -export-symbols-regex.  То есть от делает

nm -B *.o |grep -E $export_symbols_regex

Правда в либтуле такой код что мне его читать противно и пермещаюсь
я по нему исключительно с помощью # и *.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [RFC] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Fri, Aug 11, 2006 at 10:44:53PM +0400, Sergey Vlasov wrote:
> После 1.1 вроде бы изменений ABI больше не было (во всяком случае,
> файл lib/obex.sym больше не менялся).

Враньё.  Точнее, lib/obex.sym действительно не менялся, а вот
изменения, затрагивающие ABI, были - между версиями 1.1 и 1.2:


    Add support for suspend after sending a header

+#define OBEX_FL_SUSPEND		0x10	/* Suspend after sending this header */

(это новый флаг для функции OBEX_ObjectAddHeader)


    Add support for empty headers for buggy OBEX servers (e.g. Teleca)

+#define OBEX_HDR_EMPTY		0x00 /* Empty header (buggy OBEX servers) */


    Add OBEX_EV_REQCHECK support

+#define OBEX_EV_REQCHECK	11	/* First packet of an incoming request has been parsed */


И что в таком случае делать?

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Sat, Aug 12, 2006 at 05:50:00PM +0400, Sergey Vlasov wrote:
> On Fri, Aug 11, 2006 at 10:44:53PM +0400, Sergey Vlasov wrote:
> > После 1.1 вроде бы изменений ABI больше не было (во всяком случае,
> > файл lib/obex.sym больше не менялся).
> 
> Враньё.  Точнее, lib/obex.sym действительно не менялся, а вот
> изменения, затрагивающие ABI, были - между версиями 1.1 и 1.2:
> 
> 
>     Add support for suspend after sending a header
> 
> +#define OBEX_FL_SUSPEND		0x10	/* Suspend after sending this header */
> 
> (это новый флаг для функции OBEX_ObjectAddHeader)
> 
> 
>     Add support for empty headers for buggy OBEX servers (e.g. Teleca)
> 
> +#define OBEX_HDR_EMPTY		0x00 /* Empty header (buggy OBEX servers) */
> 
> 
>     Add OBEX_EV_REQCHECK support
> 
> +#define OBEX_EV_REQCHECK	11	/* First packet of an incoming request has been parsed */
> 
> 
> И что в таком случае делать?

Если добавились новые флаги, тогда вешать эти функции, к которым идут
новые флаги, на новый интерфейс 1.2 -- чтобы на интерфейсе 1.2 эти
функции были с двумя собаками.  А в качестве совместимости прицепить
эти же функции на интерфейс 1.1, но с одной собакой.

Тогда весь новый код, который потенциально использует новые флаги, сядет
на 1.2, а старый код по-прежнему будет видеть 1.1.

Как это делать с ходу не скажу, проще попробовать.
В dsohowto про это есть.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

On Sat, Aug 12, 2006 at 05:32:57PM +0400, Alexey Tourbin wrote:
> > Кстати, а обязан ли каждому паттерну в local соответствовать хотя бы
> > один реально существующий символ?
> 
> Кстати, и в списке global каждому элементу в общем-то не обязан
> соответствовать какой-либо реально существующий символ (сюрприз!).

Действительно сюрприз.  Хм, и даже GNU extension для этого не
написали...

> Филькина грамота этот version script в общем.
> 
> > Если нет, можно попробовать
> > сгенерировать что-то такого типа:
> > 
> > local:
> > 	[^BFIO]*;
> > 	O[^B]*;
> > 	OB[^E]*;
> > 	OBE[^X]*;
> > 	OBEX[^_]*;
> > 	OBEX_[^....]*;
> > 	...
> > 	OBEX_TransportDisconnec[^t]*;
> > 	OBEX_TransportDisconnect?*;
> > 	...
> > 
> > Хотя как бы с такими паттернами не напороться на баги в каком-нибудь
> > кривом сановском линкере (или там опции всё равно другие?), или старых
> > binutils.
> 
> В каком смысле сгенерировать?

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

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

Только вот для этого нужно вызывать и парсить вывод, например, nm, что
в общем случае нетривиально (libtool занимается подобными вещами, но
читать этот код и соответствующие тесты для autoconf страшно).

> Кстати, интересная идея мне в голову пришла: в libtool нужно добавить
> новую опцию: --version-script (похожую на --export-symbols).  Тогда на
> платформах, которые не поддерживают versioning, libtool смог бы
> схлопывать карту verion script в список export symbols.  В случае, если
> список эксклюзивный и все символы явно перечислены, тогда вообще всё
> просто и это дается чем-то вроде
> 
> perl -lne '/^\s+(\w+);/&&print$1'
> 
> или то же самое на sed'е, хотя перл кажется более портабельный чем sed.

sed как можно считать всегда доступным, поскольку он используется в
configure; правда, в POSIX, как обычно, функциональность весьма
ограничена.

> Но в общем виде конечно нужен парсер и работа с объектным материалом, а
> это с этим уже больше сложностей.  Но в принципе это должно делаться
> где-то на уровне libtool.  На то он и libtool.
> 
> Либтул ведь сейчас генерирует из списка карту, что конечно же не фокус.
> А вот обратно ему пока слабо.

Ну это уже не ко мне...

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

On Sat, Aug 12, 2006 at 06:05:05PM +0400, Alexey Tourbin wrote:
> On Sat, Aug 12, 2006 at 05:50:00PM +0400, Sergey Vlasov wrote:
> > On Fri, Aug 11, 2006 at 10:44:53PM +0400, Sergey Vlasov wrote:
> > > После 1.1 вроде бы изменений ABI больше не было (во всяком случае,
> > > файл lib/obex.sym больше не менялся).
> > 
> > Враньё.  Точнее, lib/obex.sym действительно не менялся, а вот
> > изменения, затрагивающие ABI, были - между версиями 1.1 и 1.2:
> > 
> > 
> >     Add support for suspend after sending a header
> > 
> > +#define OBEX_FL_SUSPEND		0x10	/* Suspend after sending this header */
> > 
> > (это новый флаг для функции OBEX_ObjectAddHeader)
> > 
> > 
> >     Add support for empty headers for buggy OBEX servers (e.g. Teleca)
> > 
> > +#define OBEX_HDR_EMPTY		0x00 /* Empty header (buggy OBEX servers) */
> > 
> > 
> >     Add OBEX_EV_REQCHECK support
> > 
> > +#define OBEX_EV_REQCHECK	11	/* First packet of an incoming request has been parsed */
> > 
> > 
> > И что в таком случае делать?

Кстати, если флаги не критичные, типа O_NOATIME, т.е. если старая
библиотека на эти флаги не реагирует и более-менее нормально работает,
тогда можно ничего не делать.

> Если добавились новые флаги, тогда вешать эти функции, к которым идут
> новые флаги, на новый интерфейс 1.2 -- чтобы на интерфейсе 1.2 эти
> функции были с двумя собаками.  А в качестве совместимости прицепить
> эти же функции на интерфейс 1.1, но с одной собакой.
> 
> Тогда весь новый код, который потенциально использует новые флаги, сядет
> на 1.2, а старый код по-прежнему будет видеть 1.1.
> 
> Как это делать с ходу не скажу, проще попробовать.
> В dsohowto про это есть.

У меня сходу не получилось при помощи одного только version script
повесить один символ на два интерфейса.  Кажется, надо прямо в код
вставлять всякие asm/.symver, это недавно было в

	Date: Wed, 9 Aug 2006 03:16:59 +0400
	From: "Dmitry V. Levin"
	Subject: Re: [devel] rpmelfsymv
	To: ALT Devel discussion list
	Message-ID: <20060808231659.GA11505@basalt.office.altlinux.org>

В общем муть какая-то.

* at продолжает засорять @devel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3154 bytes --]

On Sat, Aug 12, 2006 at 06:36:34PM +0400, Alexey Tourbin wrote:
> Кстати, если флаги не критичные, типа O_NOATIME, т.е. если старая
> библиотека на эти флаги не реагирует и более-менее нормально работает,
> тогда можно ничего не делать.

В данном случае флаги критичные.  Причём OBEX_EV_REQCHECK - это флаг,
который библиотека передаёт в callback, поэтому новую версию придётся
вешать на OBEX_Init.

> У меня сходу не получилось при помощи одного только version script
> повесить один символ на два интерфейса.  Кажется, надо прямо в код
> вставлять всякие asm/.symver, это недавно было в
> 
> 	Date: Wed, 9 Aug 2006 03:16:59 +0400
> 	From: "Dmitry V. Levin"
> 	Subject: Re: [devel] rpmelfsymv
> 	To: ALT Devel discussion list
> 	Message-ID: <20060808231659.GA11505@basalt.office.altlinux.org>
> 
> В общем муть какая-то.

Именно.

Совсем просто даже через asm не получается:

__asm__(".symver real_OBEX_Init,OBEX_Init@@OPENOBEX_1.2");
__asm__(".symver real_OBEX_Init,OBEX_Init@OPENOBEX_1.0");

Независимо от порядка получаю:

{standard input}: Assembler messages:
{standard input}:12: Error: multiple versions [`OBEX_Init@OPENOBEX_1.0'|`OBEX_Init@@OPENOBEX_1.2'] for symbol `real_OBEX_Init'

Приходится делать так:

__asm__(".symver real_OBEX_Init,OBEX_Init@@OPENOBEX_1.2");
__asm__(".globl old_OBEX_Init");
__asm__(".set old_OBEX_Init, real_OBEX_Init");
__asm__(".symver old_OBEX_Init,OBEX_Init@OPENOBEX_1.0");

Т.е., для каждой версии необходим отдельный промежуточный символ.  И
настоящую функцию приходится переименовывать, иначе потом при линковке
получается multiple definition of `OBEX_Init'.

Что ещё хуже - в libalsa я нашёл следующий кусок:

#ifdef __powerpc64__
# define symbol_version(real, name, version) 			\
	__asm__ (".symver " #real "," #name "@" #version);	\
	__asm__ (".symver ." #real ",." #name "@" #version)
# define default_symbol_version(real, name, version) 		\
	__asm__ (".symver " #real "," #name "@@" #version);	\
	__asm__ (".symver ." #real ",." #name "@@" #version)
#else
# define symbol_version(real, name, version) \
	__asm__ (".symver " #real "," #name "@" #version)
# define default_symbol_version(real, name, version) \
	__asm__ (".symver " #real "," #name "@@" #version)
#endif

И даже хуже:

#ifdef __powerpc64__
#define use_default_symbol_version(real, name, version) \
	__asm__ (".weak " #name); 			\
	__asm__ (".weak ." #name); 			\
	__asm__ (".set " #name "," #real);		\
	__asm__ (".set ." #name ",." #real)
#else
#if defined(__alpha__) || defined(__mips__)
#define use_default_symbol_version(real, name, version) \
        __asm__ (".weak " #name); \
        __asm__ (#name " = " #real)
#else
#define use_default_symbol_version(real, name, version) \
	__asm__ (".weak " #name); \
	__asm__ (".set " #name "," #real)
#endif

Т.е., на powerpc64 у каждой функции не один, а два символа, на которые
надо вешать версии, а на alpha и mips не работает .set.

Но примеров вешания разных версий на один символ нет даже там.  Вообще
такое кто-нибудь делает?

> * at продолжает засорять @devel
* vsu думает, не забить ли уже на всё это

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On Sat, Aug 12, 2006 at 07:49:01PM +0400, Sergey Vlasov wrote:
> В данном случае флаги критичные.  Причём OBEX_EV_REQCHECK - это флаг,
> который библиотека передаёт в callback, поэтому новую версию придётся
> вешать на OBEX_Init.
> 
> > У меня сходу не получилось при помощи одного только version script
> > повесить один символ на два интерфейса.  Кажется, надо прямо в код
> > вставлять всякие asm/.symver, это недавно было в
> > 
> > 	Date: Wed, 9 Aug 2006 03:16:59 +0400
> > 	From: "Dmitry V. Levin"
> > 	Subject: Re: [devel] rpmelfsymv
> > 	To: ALT Devel discussion list
> > 	Message-ID: <20060808231659.GA11505@basalt.office.altlinux.org>
> > 
> > В общем муть какая-то.
> 
> Именно.
> 
> Совсем просто даже через asm не получается:
> 
> __asm__(".symver real_OBEX_Init,OBEX_Init@@OPENOBEX_1.2");
> __asm__(".symver real_OBEX_Init,OBEX_Init@OPENOBEX_1.0");

[...]

> Т.е., на powerpc64 у каждой функции не один, а два символа, на которые
> надо вешать версии, а на alpha и mips не работает .set.
> 
> Но примеров вешания разных версий на один символ нет даже там.  Вообще
> такое кто-нибудь делает?
> 
> > * at продолжает засорять @devel
> * vsu думает, не забить ли уже на всё это

Одинаковые символы с разными версиями -- это уже black magic, который
нужен только для библиотек типа glibc, от которых зависит сто тыщ мильён
пакетов.

Тут можно сделать вот что:

1) сменить soname; или
2) повесить все функции, которые используют новые флаги, на новый
интерфейс 1.2; *и* удалить все старые интерфейсы, на которых висели
какие-либо из этих функций.  Поскольку интерфейсов до этого не было,
фактически имеет смысл повесить все экспортируемые функции на интерфейс 1.2.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Sun, Aug 13, 2006 at 11:51:58AM +0400, Alexey Tourbin wrote:
> Одинаковые символы с разными версиями -- это уже black magic, который
> нужен только для библиотек типа glibc, от которых зависит сто тыщ мильён
> пакетов.
> 
> Тут можно сделать вот что:
> 
> 1) сменить soname; или
> 2) повесить все функции, которые используют новые флаги, на новый
> интерфейс 1.2; *и* удалить все старые интерфейсы, на которых висели
> какие-либо из этих функций.  Поскольку интерфейсов до этого не было,
> фактически имеет смысл повесить все экспортируемые функции на интерфейс 1.2.

А вот это, к сожалению, не работает.  В dsohowto написано, что по
такому принципу работает symbol versioning в Solaris: при внесении в
интерфейс изменений, которые расширяют функциональность, но не ломают
совместимость со старыми бинарниками, соответствующие символы в
map-файле _переносятся_ в новую версию, базирующуюся на старой.  При
запуске старых приложений, когда dynamic linker обнаруживает, что
символ с нужной версией отсутствует в библиотеке, в Solaris он может
вместо запрошенной версии использовать более позднюю.  Однако в Linux
такой фокус не проходит - требуется именно символ со старой версией,
автозамена на более новую версию не производится.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On Sun, Aug 13, 2006 at 04:13:09PM +0400, Sergey Vlasov wrote:
> On Sun, Aug 13, 2006 at 11:51:58AM +0400, Alexey Tourbin wrote:
> > Одинаковые символы с разными версиями -- это уже black magic, который
> > нужен только для библиотек типа glibc, от которых зависит сто тыщ мильён
> > пакетов.
> > 
> > Тут можно сделать вот что:
> > 
> > 1) сменить soname; или
> > 2) повесить все функции, которые используют новые флаги, на новый
> > интерфейс 1.2; *и* удалить все старые интерфейсы, на которых висели
> > какие-либо из этих функций.  Поскольку интерфейсов до этого не было,
> > фактически имеет смысл повесить все экспортируемые функции на интерфейс 1.2.
> 
> А вот это, к сожалению, не работает.  В dsohowto написано, что по
> такому принципу работает symbol versioning в Solaris: при внесении в
> интерфейс изменений, которые расширяют функциональность, но не ломают
> совместимость со старыми бинарниками, соответствующие символы в
> map-файле _переносятся_ в новую версию, базирующуюся на старой.  При
> запуске старых приложений, когда dynamic linker обнаруживает, что
> символ с нужной версией отсутствует в библиотеке, в Solaris он может
> вместо запрошенной версии использовать более позднюю.  Однако в Linux
> такой фокус не проходит - требуется именно символ со старой версией,
> автозамена на более новую версию не производится.

Я и говорю: если удалить старый интерфейс полностью, то будет анмет.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Sun, Aug 13, 2006 at 04:20:44PM +0400, Alexey Tourbin wrote:
> Я и говорю: если удалить старый интерфейс полностью, то будет анмет.

Тогда чем это лучше смены soname?

Вообще у меня сейчас получилось вот что:

#define symver_concat(pre, post)	pre##post
#define symver_tmp_name(name, line)	symver_concat(name##_version_, line)

#define symver_set_weak(real) \
	__asm__ (".weak " #real); \
	__asm__ (".weak ." #real)

#define symver_define_alias(alias, name) \
	extern __typeof__ (name) alias __attribute__((__alias__(#name)))

#define symver_set_version(real, name, version) \
	__asm__ (".symver " #real "," #name "@" version); \
	__asm__ (".symver ." #real ",." #name "@" version)

#define symver_declare_version(alias, name, version) \
	symver_define_alias(alias, name); \
	symver_set_version(alias, name, version)

#define symbol_version(name, version) \
	symver_declare_version(symver_tmp_name(name, __LINE__), \
			       name, #version)

#define symbol_default_version(name, version) \
	symver_set_weak(name); \
	symver_declare_version(symver_tmp_name(name, __LINE__), \
			       name, "@" #version)

Используется как-то так:

symbol_default_version(junk, JUNK_1.1);
symbol_version(junk, JUNK_1.0);

При этом в map-файле всё равно приходится писать все символы во всех
версиях:

JUNK_1.0 {
global:
	junk;
local:
	*;
};

JUNK_1.1 {
global:
	junk;
} JUNK_1.0;

Использование ".weak" позволяет не менять основной код, где
экспортируемые функции просто определяются как глобальные (без ".weak"
получается конфликт из-за того, что версия с "@@" генерирует
фактически полноценное определение символа).  Символы с ".",
предположительно нужные на powerpc64, вроде бы не мешают и на i586.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]

On Sun, Aug 13, 2006 at 06:55:00PM +0400, Sergey Vlasov wrote:
> On Sun, Aug 13, 2006 at 04:20:44PM +0400, Alexey Tourbin wrote:
> > Я и говорю: если удалить старый интерфейс полностью, то будет анмет.
> 
> Тогда чем это лучше смены soname?

Ничем; разве что soname останется как в апстриме, и код, скомилированный
elsewhere, будет работать.  Это похоже вот на что: сменить soname, но
поставить симлинк на старый soname и записать его в Provides.

> Вообще у меня сейчас получилось вот что:
> 
> #define symver_concat(pre, post)	pre##post
> #define symver_tmp_name(name, line)	symver_concat(name##_version_, line)
> 
> #define symver_set_weak(real) \
> 	__asm__ (".weak " #real); \
> 	__asm__ (".weak ." #real)
> 
> #define symver_define_alias(alias, name) \
> 	extern __typeof__ (name) alias __attribute__((__alias__(#name)))
> 
> #define symver_set_version(real, name, version) \
> 	__asm__ (".symver " #real "," #name "@" version); \
> 	__asm__ (".symver ." #real ",." #name "@" version)
> 
> #define symver_declare_version(alias, name, version) \
> 	symver_define_alias(alias, name); \
> 	symver_set_version(alias, name, version)
> 
> #define symbol_version(name, version) \
> 	symver_declare_version(symver_tmp_name(name, __LINE__), \
> 			       name, #version)
> 
> #define symbol_default_version(name, version) \
> 	symver_set_weak(name); \
> 	symver_declare_version(symver_tmp_name(name, __LINE__), \
> 			       name, "@" #version)
> 
> Используется как-то так:
> 
> symbol_default_version(junk, JUNK_1.1);
> symbol_version(junk, JUNK_1.0);
> 
> При этом в map-файле всё равно приходится писать все символы во всех
> версиях:
> 
> JUNK_1.0 {
> global:
> 	junk;
> local:
> 	*;
> };
> 
> JUNK_1.1 {
> global:
> 	junk;
> } JUNK_1.0;
> 
> Использование ".weak" позволяет не менять основной код, где
> экспортируемые функции просто определяются как глобальные (без ".weak"
> получается конфликт из-за того, что версия с "@@" генерирует
> фактически полноценное определение символа).  Символы с ".",
> предположительно нужные на powerpc64, вроде бы не мешают и на i586.

$ tail -3 func.c
void func() { }
symbol_default_version(func, FUNC_1.2);
symbol_version(func, FUNC_1.1);
$ gcc -E func.c |tail -3
void func() { }
__asm__ (".weak " "func"); __asm__ (".weak ." "func"); extern __typeof__ (func) func_version_28 __attribute__((__alias__("func"))); __asm__ (".symver " "func_version_28" "," "func" "@" "@" "FUNC_1.2"); __asm__ (".symver ." "func_version_28" ",." "func" "@" "@" "FUNC_1.2");
extern __typeof__ (func) func_version_29 __attribute__((__alias__("func"))); __asm__ (".symver " "func_version_29" "," "func" "@" "FUNC_1.1"); __asm__ (".symver ." "func_version_29" ",." "func" "@" "FUNC_1.1");
$

[ Хм... а я почему-то думал, что конкатенацией строк занимается препроцессор... ]

$ objdump -tw func.o |grep func
func.o:     file format elf32-i386
00000000 l    df *ABS*  00000000 func.c
00000000  w    F .text  00000005 func
00000000 g     F .text  00000005 func_version_28
00000000 g     F .text  00000005 func_version_29
00000000 g     F .text  00000005 func@@FUNC_1.2
00000000 g     F .text  00000005 func@FUNC_1.1
$

Здорово!  Эти макросы стоит куда-нибудь отдельно запаковать; только
трудно сказать, куда именно.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]

On Sun, Aug 13, 2006 at 08:00:10PM +0400, Alexey Tourbin wrote:
> On Sun, Aug 13, 2006 at 06:55:00PM +0400, Sergey Vlasov wrote:
> > Вообще у меня сейчас получилось вот что:
> > 
> > #define symver_concat(pre, post)	pre##post
> > #define symver_tmp_name(name, line)	symver_concat(name##_version_, line)
> > 
> > #define symver_set_weak(real) \
> > 	__asm__ (".weak " #real); \
> > 	__asm__ (".weak ." #real)
> > 
> > #define symver_define_alias(alias, name) \
> > 	extern __typeof__ (name) alias __attribute__((__alias__(#name)))

Кстати, если сюда добавить __visibility__("default") и потребовать,
чтобы через эти макросы экспортировались все символы, а не только те,
для которых требуется несколько версий (как делается в libalsa), можно
ещё и компилить весь код с -fvisibility=hidden, что даёт компилятору
дополнительные возможности для оптимизации кода.

> > 
> > #define symver_set_version(real, name, version) \
> > 	__asm__ (".symver " #real "," #name "@" version); \
> > 	__asm__ (".symver ." #real ",." #name "@" version)
> > 
> > #define symver_declare_version(alias, name, version) \
> > 	symver_define_alias(alias, name); \
> > 	symver_set_version(alias, name, version)
> > 
> > #define symbol_version(name, version) \
> > 	symver_declare_version(symver_tmp_name(name, __LINE__), \
> > 			       name, #version)
> > 
> > #define symbol_default_version(name, version) \
> > 	symver_set_weak(name); \
> > 	symver_declare_version(symver_tmp_name(name, __LINE__), \
> > 			       name, "@" #version)
> > 
> > Используется как-то так:
> > 
> > symbol_default_version(junk, JUNK_1.1);
> > symbol_version(junk, JUNK_1.0);
> > 
> > При этом в map-файле всё равно приходится писать все символы во всех
> > версиях:
> > 
> > JUNK_1.0 {
> > global:
> > 	junk;
> > local:
> > 	*;
> > };
> > 
> > JUNK_1.1 {
> > global:
> > 	junk;
> > } JUNK_1.0;

Если через макросы должно экспортироваться всё, получается
дублирование информации в map-файле и макросах - следовательно, в этом
случае map-файл надо генерировать (правда, куда-то ещё надо положить
информацию об используемых версиях и их взаимосвязях).

> Здорово!  Эти макросы стоит куда-нибудь отдельно запаковать; только
> трудно сказать, куда именно.

К ним ещё должны прилагаться соответствующие тесты для autoconf
(которые ещё надо написать).

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libopenobex-1.3 symbol versioning patch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Sat, Aug 12, 2006 at 05:00:37PM +0400, Sergey Vlasov wrote:
> Кстати, а обязан ли каждому паттерну в local соответствовать хотя бы
> один реально существующий символ?

Нет, любому паттерну как в local, так и в global может не соответствовать
ни одного символа.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [RFC] libopenobex-1.3 symbol versioning patch

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Fri, Aug 11, 2006 at 10:44:53PM +0400, Sergey Vlasov wrote:
> Прошу высказать замечания по прилагаемому патчу, который добавляет
> symbol versioning в libopenobex-1.3 (сейчас в Сизифе лежит 1.0.1).

На самом деле пока нам можно просто ничего не делать - между версиями
1.0.1 и 1.1 у libopenobex сменился soname, так что сейчас проблем с
устаревшими версиями библиотеки всё равно не будет (они могли бы
возникнуть, если бы кто-то собрал версию 1.1 или 1.2).

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]