LINUX.ORG.RU
ФорумTalks

Почему почти не используют динамическую загрузку shared library?


1

1

Есть много программ, и они позволяют при компиляции выбирать, с какими библиотеками линковаться, и от этого зависит функционал.

В дебиане линкуют со всем чем можно, давая максимальный функционал, но за счет огромного количества зависимостей. В других дистрибутивах линкуют с меньшим.

Но сам корень проблемы в том, что почти все программы лишь один раз позволяют выбрать, с кем линковаться - при компиляции.

Единственные известные мне исключения - FF и компания, подгружающие libflashplayer.so на лету, а также Xorg, грузящий драйвера.

Почему так редко используют динамическую загрузку библиотек? Это позволило бы не тянуть всевозможные зависимости или же не перекомпилировать каждый раз для увеличения функционала

★★★★★

Последнее исправление: cvs-255 (всего исправлений: 2)

Nss (name service switch), PAM, 100500 плагиноа ко всему подряд, Xorg,- и вообще много всего. Тебе мало?

no-dashi ★★★★★
()
Ответ на: комментарий от AS

В данном случае ABI и API фиксирован.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от vasily_pupkin

Да? Честно, не сильно пытался разбираться в этих вещах на таком уровне, если так, то замечательно :)

buddhist ★★★★★
()

Почему так редко используют динамическую загрузку библиотек?

Потому что цикл разработки&деплоя среднего FOSS приложения рассчитан *только* на существование внутри дистрибутива свободно распространяемой ОС. И совершенно не рассчитаны на функционирование в режиме ISV.

Если по простому - линуксовые программы это аналог даже не программ идущих в составе венды, а прямо таки user32.dll. То есть кода намертво привязанного к внутренностям ос и распространяемого только в составе дистрибутива виндовса.

Программ же которые бы распространялись(и разрабатывались) как виндовые приложения от сторонних разработчиков - в линуксе почти нет. Есть конечно фаерфокс - но у него и тарболл есть в котором все есть.

В линуксе же есть два установившихся вида деплоя - make install и пакетные манагеры являющиеся расширением первого метода. Ни там ни там dlopen ненужен - точнее его исполняет код загрузчика при старте. Метод деплоя же через независимый тарболл или через дистрибутиво-независимые пакеты в дикой природе практически не присутствует. Его себе могут позволить только крупные игроки типа либреофиса или мозиллы.

Теперь сами подумайте - а зачем делать dlopen в своем коде если им никто не будет пользоваться, а лишних багов это внесет огого? И внесет багов много именно потому что этим никто не пользуется, это решение абсолютно не отработано. Иначе были бы стопитсот библиотек, инфраструктура аналогичная дистрибутивной итак далее. Были бы *популярные* проекты «инсталлируй наш дебьян-пакет в один клик на любой дистр»
В общем, это проблема по сути не техническая а социально-техническая.

kernel ★★☆
()
Ответ на: комментарий от buddhist

С того, что под винду не существует «годных» реализаций.

gnu libtool существовал еще тогда когда вы по подъездам клей нюхали, а то под стол пешком ходили :D

kernel ★★☆
()
Ответ на: комментарий от kernel

gnu libtool раздражал всех еще тогда ...

починил же :)

buddhist ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.