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

[Alexey Lubimov <avl@l14.ru>]

Dmitry V. Levin пишет:
> 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

Это да. Только по моему перед библиотекой ключик -lm нужен.

> 
> На практике так обычно не линкуются.

По моему так линкуют только личные библиотеки из своего же состава и то 
нечасто.

> 
> 
>>>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L
>>>- с библиотекой libdb4.0, то во время запуска программы A в памяти
>>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
>>
>>То, что  вся цепочка слинкованных программ должна быть связана с одной 
>>версией libdb4.1 естественно.
>>Но проблема то поднималась другая. Лишние связи, когда при сборке 
>>программ могут быть подсунуты случайные версии и даже вперемешку. Разве 
>>не так?
> 
> 
> Разве это другая задача?

Если речь идет именно о сборке программ в отдельном окружении без 
конкурирующих пакетов - да.

В этом случае, есть "дефолтная" libdb4.0 и есть "несовместимая с ней 
альтернатива" libdb4.1
Программы собираются с libdb4.1
Если программа требует именно libdb4-compat4.0, то она собирается с ним 
и помечается, как libdb4-incompatible (на самом деле само по себе 
buidrequires на libdb4-compat4.0 и будет этим признаком).

При операции релиза (типа sandcl endpocket sisyphus) репозитария  можно 
хоть полдня ползать по репозитарию скриптами, раскрывая цепочки 
зависимостей (buildrequires - они железные и проверены в bte) пакетов и 
проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb.

> 
> Как вы сможете отличить случайную линковку от неслучайной?

Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со 
ступицы, а потом теряют тормоза от перегрева.

Чтобы определить случайность линковки в общем случае, надо 
протестировать программу по полной программе. Имхо, сизиф страдает от 
таких "оптимизаций" поболее, чем от их отсутствия.

У программ есть авторы и они обычно пишут список зависимостей. Далее 
второе (расширяющее) приближение - сборка. На этом все начные методы 
заканчиваются иначинается либо гадание либо тупая ручная статистика 
учета возникших от оптимизации проблем.

Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто 
не реализуемо в принципе.

> Есть, конечно, некоторые приёмы, которые позволяют определить,
> используется ли данной программой/библиотекой данная библиотека напрямую.

ldd?
имхо не слишком надежно.
> 
> Проще и эффективнее поступить так:
> если есть источник случайных зависимостей, то его надо закрыть.

ага. только не уничтожать при этом пакеты. а выборочно загружать в бте.

> 
> 
>>Рекурсивно разворачивать во время сборки все связи и завершать сборку 
>>при конфликте версий через другие линкуемые библиотеки имхо совсем 
>>другая задача. не так?
> 
> 
> Это не задача, это приём, который имеет смысл применить, хотя он и не
> может выявить всё, например, проблемы, возникающие при динамической
> загрузке модулей.
> 
> Предложите, как лучше оформить интерфейс: как описать множество
> конфликтующих библиотек (который будет меняться), как включать/выключать
> эту проверку при сборке того или иного пакета.

Я вижу это таким образом.

Должна быть практически не меняющаяся по именам умолчальная среда с 
одним претендентом по каждой альтернативе.
один gcc, glibc, libpng, libdb4 etc

Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 
libng-compat2 libdb5-compat0 etc

Замечу, что основные имена являются скользящими. То есть libpng когда то 
было версии 2, а потом без изменения имени становится версии3, а вот 
-compat уже ссылаются на определенную версию и заморожены в таком 
состоянии.

пакеты в нормальном состоянии должны требовать в BuildRequires  gcc, 
glibc, libpng, libdb4.

Если пакет перестает собираться с новой версией и начинает требовать 
-compat, то в BuildRequires вручную ставится зависимость на конкретный 
compat.

Зависимость на -compat и является признаком замороженного на версии пакета.

Пишуться правила типа libdb conflicts libdb-compat

При пересборке факт смешанного использования библиотек через третью 
программ не ловится. Его даже и ловить не надо.

После пересборки репозитария, по нему запускается скрипт проверки, 
рекурсивно разворачивает зависимости и по правилам ловит факт смешивания 
конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. 
То ли выбросить что либо из репозитария, то ли пересобрать по другому.


> 
>>>>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
>>>>>Последствиями" для базы rpm, в частности.
>>>>>
>>>>
>>>>А bte зачем делали?
>>>
>>>О чём это вы?  BTE - это миф.
>>>Если программа A из предыдущего примера не используется во время сборки
>>>других пакетов, то выявить её неработоспособность путём пересборки Сизифа
>>>не удастся.
>>>
>>
>>Это совсем из другой оперы. Предлагается то курочить aclocal, то есть 
>>влиять исключительно на процесс сборки. А какой тогда в этом смысл, если 
>>программа в сборке просто не участвует?
> 
> 
> Кто предлагает курочить aclocal, какая программа не участвует в сборке?
> Ничего не понял.

модифицированный libtoolize Морозов предложил запускать вместо aclocal.

при сборке может отсутствовать та, третья программа, через которую 
библиотеки и конфликтуют.

Вот эта, которая L:
--------------
 >>>Если программа A была собрана с библиотекой L и с libdb4.1, а 
библиотека L
 >>>- с библиотекой libdb4.0, то во время запуска программы A в памяти
 >>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
 >>
--------------


> 
> 
>>Я так понял, что если на этапе сборки не были доступны *.la, то во время 
>>запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
>>недостатком информации при сборке остаются.
> 
> 
> Я понимаю ситуацию ровно наоборот.
> Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки
> информации нет, ни во время сборки, ни во время работы.
> 
> Фактически, как уже было сказано неоднократно, библиотечные .la-файлы
> бывают нужны для статической сборки, а модульныке - для динамической
> загрузки модулей средствами ltdl.

Да пока что вы противоречите друг другу с Морозовым, а я просто  не 
знаю, кто из вас прав :(


>>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
>>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов.
> 
> 
> Что такое спецслучаи и кто будет их отлавливать?

майнтейнер. прога то либо не будет собираться, либо работать.


> Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
> разные libdb4.X?  А если это невозможно?

В бте?
такие случаи автоматом не решаются. Придется собирать консилиум 
майнтейнеров и решать, кого убрать. Как сегодня и происходит.


>>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?
> 
> 
> Есть и будет появляться новое всегда, когда у библиотеки меняется soname.

Не так. Это когда библиотеки обновляюти вместе с тем под другим именем 
оставляют старые версии. Если библиотеки просто обновляют, то либо прога 
собирается с ней, либо нет, но левых зависимостей все равно не возникает.