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 .

Таким образом, все найденные системные макросы будут иметь приоритет
перед теми, которые разработчики умудрились впихнуть себе. С другой
стороны, конечно, по сусалам надо бить за такое включение, и за способ
его обруливания :-)).