From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 9 Jan 2004 15:46:19 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] .a vs .so Message-ID: <20040109094619.GG2244@pyro.hopawar.private.net> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G/vVCphCGw+yuveY" Content-Disposition: inline In-Reply-To: <20040108201457.GA28535@nomad.office.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: Fri, 09 Jan 2004 09:46:24 -0000 Archived-At: List-Archive: List-Post: --G/vVCphCGw+yuveY Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 позволяет обойти и тех последних. В общем, думаю, в нынешней ситуации все равно приходится разбираться некоторыми пакетами, причем, с теми, кто _делает все правильно_. В моём способе разбираться приходится с теми, кто делает что-либо неправильно. По-моему, альтернатива более здравая. Я, если пороюсь в здешних архивах, накопаю Ваше письмо о том, что Вы готовы бороться за правильные решения :-)). > Чего хочется добиться? Решения этой задачи с лишними зависимостями > (которые, как мы знаем, могут порождать жуткие проблемы в runtime), не > вдаваясь в особенности устройства кривизны каждого пакета в Сизифе. Нет, это неполная постановка задачи. Требуется детализация. > Как при этом сохранить возможность линковать статические приложения? > Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется. Я предложил бы паковать все. > Я предположил, что их можно просто восстанавливать скриптом при > необходимости по уже установленным разделяемым библиотекам. В какой момент? Теоретически, конечно, такая возможность есть, но, по-моему, это странно: сначала откзываться от какой-либо информации, потом ее вытаскивать по каким-либо "внешним" факторам. К тому же, я не уверен, что если в зависимости для _динамических_ библиотек попадет какая-либо чисто статическая (ну, вообщем-то, такое устроить можно запросто), то мы не потеряем в этом месте информацию безвозвратно. --G/vVCphCGw+yuveY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE//nhrX5DZdJn19V0RAsAGAJ4+7niE0rOL3uWP5dB5v23qAxIwFgCbBpHF K/DCrwhzg2/tgj4G6JJIYKY= =vE5w -----END PGP SIGNATURE----- --G/vVCphCGw+yuveY--