From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 8 Jan 2004 21:43:27 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?8MHU3iDOwSBsaWJ0?= =?koi8-r?B?b29sINDSzw==?= link_all_deplibs Message-ID: <20040108154327.GH2244@pyro.hopawar.private.net> References: <20040106102757.GK12479@pyro.hopawar.private.net> <200401061454.07492.warframe@altlinux.ru> <20040106135453.GB3572@localhost.localdomain> <200401081751.42510.zerg@altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0Ed1hDcWxc3B7cn" Content-Disposition: inline In-Reply-To: <200401081751.42510.zerg@altlinux.org> User-Agent: Mutt/1.4i X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 15:43:30 -0000 Archived-At: List-Archive: List-Post: --y0Ed1hDcWxc3B7cn Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 . Таким образом, все найденные системные макросы будут иметь приоритет перед теми, которые разработчики умудрились впихнуть себе. С другой стороны, конечно, по сусалам надо бить за такое включение, и за способ его обруливания :-)). --y0Ed1hDcWxc3B7cn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE//XqfX5DZdJn19V0RAiECAJ4vct2RZZa11hLSfnKdkIVHCYXgQwCfZD47 LVvCNl9VdrhbENOe+/yb/b8= =mwkF -----END PGP SIGNATURE----- --y0Ed1hDcWxc3B7cn--