[devel] .a vs .so

[Dmitry V. Levin]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20040110/2ba08571/attachment-0001.bin>