[devel] Re: .a vs .so
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Вс Янв 11 21:10:39 MSK 2004
On Sun, Jan 11, 2004 at 07:57:34PM +0300, Алексей Любимов wrote:
> Dmitry V. Levin пишет:
> >On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
> >
> >>>5. После обнаружения .la-файла, оригинальный (неправленный Альтом)
> >>>libtool
> >>>использует информацию из dependency_libs для рекурсивного разворачивания
> >>>цепочки зависимостей библиотек до самого низа. При этом очевидно, что
> >>>при некоторых условиях возможна ситуация, когда одновременно линкеру
> >>>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
> >>>
> >>Вопрос
> >>а если в системе стоят только libdb4.0 и libdb4.1, libdb4.1-devel (со
> >>статиком)
> >>будет подхвачена libdb4.0?
> >
> >Во время сборки или во время запуска?
> >
> 1 момент. - Во время сборки.
> При отсутствии -devel, разве может программа прилинковаться к библиотеке.
Теоретически - да, например,
gcc sample.c /lib/libdb-4.1.so -o sample
На практике так обычно не линкуются.
> >Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L
> >- с библиотекой libdb4.0, то во время запуска программы A в памяти
> >окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
>
> То, что вся цепочка слинкованных программ должна быть связана с одной
> версией libdb4.1 естественно.
> Но проблема то поднималась другая. Лишние связи, когда при сборке
> программ могут быть подсунуты случайные версии и даже вперемешку. Разве
> не так?
Разве это другая задача?
Как вы сможете отличить случайную линковку от неслучайной?
Есть, конечно, некоторые приёмы, которые позволяют определить,
используется ли данной программой/библиотекой данная библиотека напрямую.
Проще и эффективнее поступить так:
если есть источник случайных зависимостей, то его надо закрыть.
> Рекурсивно разворачивать во время сборки все связи и завершать сборку
> при конфликте версий через другие линкуемые библиотеки имхо совсем
> другая задача. не так?
Это не задача, это приём, который имеет смысл применить, хотя он и не
может выявить всё, например, проблемы, возникающие при динамической
загрузке модулей.
Предложите, как лучше оформить интерфейс: как описать множество
конфликтующих библиотек (который будет меняться), как включать/выключать
эту проверку при сборке того или иного пакета.
> >>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
> >>>Последствиями" для базы rpm, в частности.
> >>>
> >>А bte зачем делали?
> >
> >О чём это вы? BTE - это миф.
> >Если программа A из предыдущего примера не используется во время сборки
> >других пакетов, то выявить её неработоспособность путём пересборки Сизифа
> >не удастся.
> >
> Это совсем из другой оперы. Предлагается то курочить aclocal, то есть
> влиять исключительно на процесс сборки. А какой тогда в этом смысл, если
> программа в сборке просто не участвует?
Кто предлагает курочить aclocal, какая программа не участвует в сборке?
Ничего не понял.
> Я так понял, что если на этапе сборки не были доступны *.la, то во время
> запуска программы хоть эти *la и не участвуют, но проблемы заложенные
> недостатком информации при сборке остаются.
Я понимаю ситуацию ровно наоборот.
Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки
информации нет, ни во время сборки, ни во время работы.
Фактически, как уже было сказано неоднократно, библиотечные .la-файлы
бывают нужны для статической сборки, а модульныке - для динамической
загрузки модулей средствами ltdl.
> >>>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
> >>>libtool подправлен таким образом, чтобы при динамической сборке на
> >>>линуксе
> >>>список dependency_libs не раскрывался вовсе (при статической все
> >>>по-прежнему).
> >>>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
> >>>вроде бы, решает все остальные.
> >>>
> >>А почему нельзя на этапе сборки просто ограничить выбор пакетов
> >>правильными зависимостями в спеке? Разве это не ограничит выбор
> >>dependency_libs?
> >
> >Вы предлагаете ликвидировать find-requires и перейти на указание
> >зависимостей собранных пакетов вручную?
> >
> Ни разу. Просто в спецслучаях указывать из нескольких альтенатив
> (libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов.
Что такое спецслучаи и кто будет их отлавливать?
Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
разные libdb4.X? А если это невозможно?
> По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?
Есть и будет появляться новое всегда, когда у библиотеки меняется soname.
--
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/20040111/967777a2/attachment-0001.bin>
Подробная информация о списке рассылки Devel