[devel] Re: .a vs .so

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

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, разве может программа прилинковаться к библиотеке.


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

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

Рекурсивно разворачивать во время сборки все связи и завершать сборку 
при конфликте версий через другие линкуемые библиотеки имхо совсем 
другая задача. не так?

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

>>>7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря,
>>>_необходима_ информация, записанная в  dependency_libs. Необходимость
>>>этой информации обусловлена [достаточно гипотетической, впрочем]
>>>возможностью наличия в зависимостях статической библиотеки без
>>>соответствующего динамического аналога (я припоминаю, что, вроде, то ли
>>>libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс
>>>всякие third-party, но это уже их головная боль, наверное.
>>>
>>>      
>>>
>>другими словами, даже деление на devel и devel-static с последующей 
>>неустановкой *-static для  сборки программы с динамической линковкой в 
>>общем случае некорректно?
>>    
>>
>
>В том случае, о котором идёт речь в 7.2, некорректно.
>Правда, у нас в Сизифе таких всего 2:
>glibc-devel (libc_nonshared.a и *crt*.o) и gcc (*crt*.o).
>И надеюсь, что не будет.
>
>  
>
>>>7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно,
>>>имя библиотеки) используется libtool'ом для обеспечения корректной работы
>>>с ltdl-модулями (см. autobook)
>>>
>>>      
>>>
>>Предыдущее предположение и здесь в силе?
>>    
>>
>
>Нет.  Во время динамической загрузки можно нормально загрузить только
>динамические модули.
>  
>

Я так понял, что если на этапе сборки не были доступны *.la, то во время 
запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
недостатком информации при сборке остаются.

>  
>
>>>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
>>>libtool подправлен таким образом, чтобы при динамической сборке на линуксе
>>>список dependency_libs не раскрывался вовсе (при статической все 
>>>по-прежнему).
>>>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
>>>вроде бы, решает все остальные.
>>>
>>>      
>>>
>>А почему нельзя на этапе сборки просто ограничить выбор пакетов 
>>правильными зависимостями в спеке? Разве это не ограничит выбор 
>>dependency_libs?
>>    
>>
>
>Вы предлагаете ликвидировать find-requires и перейти на указание
>зависимостей собранных пакетов вручную?
>  
>
Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов.
По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?