[devel] Патч на libtool про link_all_deplibs
Alexey Morozov
=?iso-8859-1?q?alex-altlinux_=CE=C1_idisys=2Eiae=2Ensk=2Esu?=
Чт Янв 8 18:43:27 MSK 2004
On Thu, Jan 08, 2004 at 05:51:42PM +0300, Sergey V Turchin wrote:
Content-Description: signed data
> > Она, скорее всего, поднимает плагины через какую-либо KDEшную
> > обвязку, которая, в свою очередь, дергает ltdl
> Да, в нынешнем виде там в имени файла s/\.la$/.so/ делается только.
Ломается загрузка модулей. Она же (ltdl) пытается "умным" name
mangling'ом заниматься, разводя конфликты имен при помощи префиксов,
которые как раз из берутся из .la файлов.
> > . В своем нынешнем
> > виде (без .la файлов, и не захаченная нездравым способом) libltdl
> > в AltLinux
> Я собираю с %undefine __libtoolize, с libtool из исходных тарболов.
> Патчи для замены lt_dlopen на dlopen не прикладываю,
> т.к. не выявил разницы в работоспособности.
См. выше. Если кто-то захочет воспользоваться ltdl'ем именно как
загрузчиком модулей, ничего не выйдет. Попробуйте сами тестовый
примерчик накатать, там с десяток строк, выдернутых, к тому же,
из autobook'а.
> > На самом деле, я С ИНТЕРЕСОМ выслушаю ВСЕ претензии по поводу
> > софта, который собирался, но перестал после libtoolize --copy
> > --force (без aclocal). И попробую эти претензии разрешить.
Ну, я уже увидел одну проблему, которую, в общем, необходимо решать.
Проблему увидел, пока собирал для Миши xmms (Кстати, Миша, я не смотрел,
Вы патч про aclocal-mess включили в сборку? Его бы подправить радикально
надо :-)).
Проблема заключается в том, что механизм aclocal изначально не слишком
рассчитан на разделение между разработчиком и дистрибьютором. Как
следствие, если дистрибьютор вынужден по каким-либо причинам говорить
aclocal, то он, строго говоря, _обязан_ иметь тот же build environment,
что и разработчик, со всеми .m4, которые последнему были нужны. Иначе
после aclocal просто не найдется половина используемых ac-макросов.
Чтобы этого избежать некоторые, хе-хе, добрые разработчики решили класть
себе в acinclude.m4 чуть ли не весь свой /usr/share/aclocal/ & Co.
В результате, мы избежав Сциллы попадаем прямиком к Харибде, когда
макросы из acinclude.m4 просто не подходят для данной сборочной системы,
а макросы, которые установлены вместе с -devel пакетами просто
игнорируются при aclocal.
Типичные симптомы видны как раз на libtool:
если пакет облибтулайзивался при помощи libtool-1.4 и включает в себя
копию libtool.m4 46-го разлива (т.е. от lt-1.4), то ltmain.sh от
libtool-1.5 не годится для такого пакета без дополнительных действий,
а именно, необходимо вычистить acinclude.m4 от всех "не своих" макросов,
и только затем говорить aclocal. Впрочем, кажется, я пока писал это все,
придумал решение:
что если говорить не просто
aclocal
, а, скажем, делать следующее:
переименовывать acinclude.m4, в, скажем, acinclude_local.m4, а затем
делать так:
aclocal -I `aclocal --print-ac-dir` -I .
Таким образом, все найденные системные макросы будут иметь приоритет
перед теми, которые разработчики умудрились впихнуть себе. С другой
стороны, конечно, по сусалам надо бить за такое включение, и за способ
его обруливания :-)).
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20040108/ab948900/attachment-0001.bin>
Подробная информация о списке рассылки Devel