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 -
обычно в релиз кладут уже сгенерированные файлы; хотя в данном случае
проблема скорее не в переносимости, а в сборочных зависимостях).