Re: [devel] Re: .a vs .so

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]