[devel] .a vs .so

Alexey Morozov =?iso-8859-1?q?alex-altlinux_=CE=C1_idisys=2Eiae=2Ensk=2Esu?=
Пт Янв 9 12:46:19 MSK 2004


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-файлу в пакет тоже ведь не очень хочется.
Я предложил бы паковать все.

> Я предположил, что их можно просто восстанавливать скриптом при
> необходимости по уже установленным разделяемым библиотекам.
В какой момент? Теоретически, конечно, такая возможность есть, но,
по-моему, это странно: сначала откзываться от какой-либо информации,
потом ее вытаскивать по каким-либо "внешним" факторам. К тому же,
я не уверен, что если в зависимости для _динамических_ библиотек
попадет какая-либо чисто статическая (ну, вообщем-то, такое устроить
можно запросто), то мы не потеряем в этом месте информацию безвозвратно.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040109/21f9fbf5/attachment-0001.bin>


Подробная информация о списке рассылки Devel