From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 10 Jan 2004 03:08:08 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] .a vs .so Message-ID: <20040110000807.GF10517@nomad.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20040106102757.GK12479@pyro.hopawar.private.net> <20040107163156.GA15124@mhz.mikhail.zabaluev.name> <3FFC48B3.9020506@l14.ru> <200401081054.01927.ilar@altlinux.ru> <20040108134326.GA13308@nomad.office.altlinux.org> <20040108143655.GC2244@pyro.hopawar.private.net> <20040108160330.GA6208@nomad.office.altlinux.org> <20040108161404.GN2244@pyro.hopawar.private.net> <20040108201457.GA28535@nomad.office.altlinux.org> <20040109094619.GG2244@pyro.hopawar.private.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qftxBdZWiueWNAVY" Content-Disposition: inline In-Reply-To: <20040109094619.GG2244@pyro.hopawar.private.net> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 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: Sat, 10 Jan 2004 00:08:12 -0000 Archived-At: List-Archive: List-Post: --qftxBdZWiueWNAVY Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Jan 09, 2004 at 03:46:19PM +0600, Alexey Morozov wrote: > On Thu, Jan 08, 2004 at 11:14:57PM +0300, Dmitry V. Levin wrote: > > Что нам даёт удаление всех .la-файлов к разделяемым библиотекам, помимо > > решения основной задачи (недопущение превращения косвенных зависимостей > > в прямые)? Гарантию того, что эти самые косвенные зависимости через > > .la-файлы не попадут в собираемые программы и библиотеки. > Ну, нынаю... Автотест работает, могу свои тесты формализовать и добавить > к стандартным libtool'овским, что еще проверять, чес-гря, не знаю. > Мои тесты, напомню, показали (на depdemo/), что gcc на линковке получает > все те библиотеки, которые потребны ему для данного вида сборки > (то есть, в динамической сборке libl3 НЕ передается, а в статической - > передается). > > Если предложите "плохую" ситуацию, которую надо промоделировать, эту > проверку тоже можно будет отправить в libtool'овые тесты. Если найду, то конечно предложу. > > Тот способ, который вы предлагаете, не даёт такой твёрдой гарантии > > просто потому, что надо в каждом конкретном случае убеждаться, что > > способ применён правильно. > Думаю, нет. libtoolize --copy --force позволяет, с одной стороны, > заменить "неправильные" ltmain.sh на "правильные", а с другой > рубит тех, кто пришел с libtool-1.4 в потрохах. > > aclocal -I `aclocal ...` -I m4 > > позволяет обойти и тех последних. В общем, думаю, в нынешней ситуации > все равно приходится разбираться некоторыми пакетами, причем, с теми, > кто _делает все правильно_. Нет, не приходится. Как правило, достаточно слепой пересборки. > В моём способе разбираться приходится с теми, кто делает что-либо > неправильно. По-моему, альтернатива более здравая. Я, если пороюсь > в здешних архивах, накопаю Ваше письмо о том, что Вы готовы бороться > за правильные решения :-)). Конечно. Не знаю, правда, как отнесутся maintainer'ы на (вообще говоря, правильное) предложение всегда использовать "libtoolize --force". Не знаю, насколько это пройдёт гладко. Поэтому и уверенности нет. > > Чего хочется добиться? Решения этой задачи с лишними зависимостями > > (которые, как мы знаем, могут порождать жуткие проблемы в runtime), не > > вдаваясь в особенности устройства кривизны каждого пакета в Сизифе. > Нет, это неполная постановка задачи. Требуется детализация. В Сизифе очень много кривых пакетов, в которых никому, кроме разве что их maintainer'ов, копаться не хочется. Нужен способ по возможности избежать перелопачивания этого множества кривых пакетов, ибо это может оказаться неподъёмной задачей на данном этапе. > > Как при этом сохранить возможность линковать статические приложения? > > Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется. > Я предложил бы паковать все. Как раньше, или как-то иначе? > > Я предположил, что их можно просто восстанавливать скриптом при > > необходимости по уже установленным разделяемым библиотекам. > В какой момент? Теоретически, конечно, такая возможность есть, но, > по-моему, это странно: сначала откзываться от какой-либо информации, > потом ее вытаскивать по каким-либо "внешним" факторам. К тому же, > я не уверен, что если в зависимости для _динамических_ библиотек > попадет какая-либо чисто статическая (ну, вообщем-то, такое устроить > можно запросто), то мы не потеряем в этом месте информацию безвозвратно. Неужели такое встречается в реальной практике? -- ldv --qftxBdZWiueWNAVY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE//0Jn9viEa8HiNCkRAgiIAJ9PDSVGBcT2kx/cF1+wic+bF8DB3gCfZbsr iq2HrbsnqTDuvlB0Y1BKRsM= =gn+E -----END PGP SIGNATURE----- --qftxBdZWiueWNAVY--