From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 11 Dec 2003 21:19:51 +0600 From: Alexey Morozov To: ALT Linux Sisyphus mailing list Subject: Re: [sisyphus] =?koi8-r?B?98/a19LB3cHR09gg?= =?koi8-r?B?yyDOwdDF3sHUwc7Oz83VICjQ0s8=?= .la) Message-ID: <20031211151951.GO14643@pyro.hopawar.private.net> References: <20031210160408.GB14643@pyro.hopawar.private.net> <20031210161658.GA6630@basalt.office.altlinux.org> <20031210212018.GA10586@localhost.localdomain> <20031211120211.GA2527@basalt.office.altlinux.org> <20031211135117.GJ14643@pyro.hopawar.private.net> <20031211143042.GA9387@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJAv8lSwuaQsYd0G" Content-Disposition: inline In-Reply-To: <20031211143042.GA9387@basalt.office.altlinux.org> User-Agent: Mutt/1.4i X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: sisyphus@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2003 15:19:53 -0000 Archived-At: List-Archive: --oJAv8lSwuaQsYd0G Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, Dec 11, 2003 at 05:30:42PM +0300, Dmitry V. Levin wrote: > > Вот этого, честно говоря, не понял. Точнее, понятно, что такую проверку > > _корректнее_ проводить в числе остальных прочих проверок способностей > > линкера/платформы, но это совсем не _обязательно_. > Как провести инициализацию link_all_deplibs=no в ltmain.sh (а не а > libtool.m4) таким образом, чтобы патч взяли в upstream? На самом деле, там все сложнее. Этот самый link_all_deplibs играет не основную роль (из-за чего, собственно, и патчить приходится). Поэтому дело скорее не в инициализации, а в неиспользовании этого параметра должным образом (скорее всего, в силу ущербности/ошибочности реализации логики) Я трейсил все это дело, в решающий момент (то есть, в этой самой проверке, после которой Ваш патч уводит на else continue), $link_all_deplibs оказывается равным no, причем, даже в случае -static что, впрочем, не мешает libtool'у все равно зацепить $dependency_libs. > > Вообще, мне кажется, в данном случае, слона лучше есть по кусочкам. > > То есть, пропихнуть (дополненный проверкой архитектуры) патч в libtool, > В libtool-1.5-alt-link_all_deplibs.patch с проверкой архитектуры всё > вроде бы нормально. Вероятно, за исключением того, что Вы делаете ее в libtool.m4, что автоматически приводит к необходимости aclocal/autoconf > > в принципе, представляется задачей реальной. > Да, представляется. Продвижение правильных патчей в upstream занимает у > меня время, сравнимое с их изготовлением. :-) Дорогу осилит, и все такое прочее :-). > > > Установить принудительный > > libtoolize --force тоже реально (проблемы могут быть только у > > действительно проблемных пакетов, но эти проблемы, _вероятнее всего_, можно > > продемонстрировать автору безотносительно данной темы), корректно > > написанные программы такую операцию точно переживут (обязаны) > Вашими бы словами... Нет, на самом деле. Мы же исходим из того, что люди вменяемы, правда? :-) > > > На втором этапе, когда патч в libtool _уже_ будет, можно будет > > разговаривать с autoconf'овыми господами на предмет: а не включить ли > > нам такую замечательную фичу, чтобы-де не руками или автоугадавом, а > > "правильно", в числе остальных ./configure'нных проверок способностей > > линкера? > А при чём тут autoconf'овые господа? Разве проверка способностей линкера - это, в конечном итоге, не их вотчина? > > > Я точно знаю, что не все пакеты-пользователи libtool переживут > > > libtoolize --force (что необходимо даже в случае хака в виде патча на > > Я предлагаю составить и огласить их список. Если делать эту операцию > > итеративно, то возни будет явно меньше, чем с вычищением .la отовсюду. > Думаю что больше. Она будет, она будет каждый раз немного другая, но она не потребует моментального пересбора всего и вся. > > > ltmain.sh), а тех, кто выдержит ещё и aclocal с autoconf, будет ещё > > > меньше. > > А вот с этим, видимо, лучше обождать. > Тогда см. вопрос #2. Ну, мне кажется, здесь нет проблемы, если [на первом этапе] проверкой возможностей линкера занимается код, включенный в ltmain.sh. > > > Надо? Нет, правда, если это надо, и если это избавит меня от необходимости > > перебирать те пакеты, для которых мне актуальна статическая линковка - > > я его сделаю. Миграция на другую платформу для девелопмента пока выглядит > > более затратным решением. > У меня нет ответа на этот вопрос. Нет, реально есть приложения, которым вынь да полож libtool-1.4? > За что вы так любите статические библиотеки? :) Мы не любим. Но нам приходится собирать статические (ужас! ужас! _полностью_ статические) приложения, без каких-либо внешних зависимостей. Типа, желание кастомера - закон, и все такое прочее. Но, возвращаясь к нашим баранам: в дополнение к существующей правке на ltmain.sh предлагается также включить туда (в ltmain.sh) код по проверке архитектуры/линкера, и выявить тех, кто не переживет libtoolize --force. Последнее достигается следующими мерами 1. Временным исправлением макроса %configure так, чтобы libtoolize --force запускался вне зависимости от неопределенного __libtoolize 2. Батч-пересборкой _программ_, использующих макрос %configure, с определением, кого расплющило 3. Батч-пересборкой программ, которые напрямую используют ./configure. С этими придется помучаться, но, думаю, счастье возможно, нужно только подумать, как именно сделать. Впрочем, специальную пересборку можно и не проводить, пустив все на самотек: когда понадобится, тогда и пересоберется. Или сломается, тогда и глядеть на него. План? --oJAv8lSwuaQsYd0G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/2IsXX5DZdJn19V0RArzjAKCS3MDEYlhdn+dc/V2f5wXTZbJUJwCfd9VM JdLMAt3xKZIZLrMHO6XGApc= =KPxP -----END PGP SIGNATURE----- --oJAv8lSwuaQsYd0G--