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.

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