[devel] Re: .a vs .so

[Алексей Любимов]

>5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool
>использует информацию из dependency_libs для рекурсивного разворачивания
>цепочки зависимостей библиотек до самого низа. При этом очевидно, что
>при некоторых условиях возможна ситуация, когда одновременно линкеру
>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
>
Вопрос
а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со 
статиком)
будет подхвачена libdb4.0?

>
>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
>Последствиями" для базы rpm, в частности.
>
А bte зачем делали?

>7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря,
>_необходима_ информация, записанная в  dependency_libs. Необходимость
>этой информации обусловлена [достаточно гипотетической, впрочем]
>возможностью наличия в зависимостях статической библиотеки без
>соответствующего динамического аналога (я припоминаю, что, вроде, то ли
>libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс
>всякие third-party, но это уже их головная боль, наверное.
>  
>
другими словами, даже деление на devel и devel-static с последующей 
неустановкой *-static для  сборки программы с динамической линковкой в 
общем случае некорректно?


>7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно,
>имя библиотеки) используется libtool'ом для обеспечения корректной работы
>с ltdl-модулями (см. autobook)
>
Предыдущее предположение и здесь в силе?

>
>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
>libtool подправлен таким образом, чтобы при динамической сборке на линуксе
>список dependency_libs не раскрывался вовсе (при статической все по-прежнему).
>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
>вроде бы, решает все остальные.
>
А почему нельзя на этапе сборки просто ограничить выбор пакетов 
правильными зависимостями в спеке? Разве это не ограничит выбор 
dependency_libs?