LINUX.ORG.RU
ФорумTalks

[бинарнодистропроблемы] Зависимости


0

1

Проблема, существующая (почти) во всех бинарных дистрибутивах та, что при установке приложений тянется много зависимостей, т.к. при компилировании мантайнеры выбрали поддержку каких-то библиотек, и их требуется установить тоже. Как, например, в дебиане mplayer скомпилирован с directfb и приходится этот libdirectfb тоже ставить, хотя он совсем не нужен.

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

Но ведь в libc есть возможность динамически подгружать shared library с помощью dlopen из библиотеки libdl, что позволяет разом избавиться от всех описанных выше проблем: при компилировании указываются только те библиотеки, которые всегда нужны и libdl, а опциональные подгружаются по мере необходимости и возможности.

я тут попробовал эту libdl, так никаких трудностей программисту она не создает. dlopen, dlsym, dlclose. Так почему она так мало используется?

★★★★★
Ответ на: комментарий от Deleted

Ну вот я убрал из системы libdirectfb-1.2.so.9, что равносильно использованию equivs

И получаю

mplayer: error while loading shared libraries: libdirectfb-1.2.so.9: cannot open shared object file: No such file or directory

Очевидно, что то же самое будет и с библиотеками, куда более тяжелыми, чем libdirectfb, но которые на самом деле не обязательны для работы приложения. Ведь я же не использую вывод в directfb? Значит реально directfb не используется. При динамической подгрузке просто не будет работать вывод в directfb, если этой библиотеки нет. При линковке при старте же я вообще не могу запустить mplayer

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

И какие же это такие библиотеки, что очень тяжелы? :}

В таких случаях пишут на деревню мейнтейнеру, так, де, и так, надо бы пакет XYZ-nofb. Но в данном случае этим заморачиваться вообще не стоит.

Deleted
()
Ответ на: комментарий от Deleted

В таких случаях пишут на деревню мейнтейнеру, так, де, и так, надо бы пакет XYZ-nofb.

В арче это за 10 минут решается правкой PKGBUILD + еще 2 минуты на заливку в AUR, чтобы с людьми поделиться профитом.

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

надо бы пакет XYZ-nofb

А заодно пакеты

xyz-nodga nofbdev nosvga nomatrixview noaa nocaca notga nov4l2

nodga-nofbdev nodga-nosvga nodga-noaa .... nodga-nofbdev-nosvga

итд.

Но зачем, когда можно просто подгружать соответствующие библиотеки «на лету» исходя из того, какой метод вывода реально используется?

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

правкой PKGBUILD + еще 2 минуты на заливку в AUR, чтобы с людьми поделиться профитом.

а как без перекомпиляции то обойтись?

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

Ну дык он при старте инициализируется, скачай исходники и выключи поддержку этого фреймбуфера (или что это там).

ms-dos32
()
Ответ на: комментарий от cvs-255

Ну если софт не поддерживает, то очевидно, что без переделывания софта никак.

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

geekless ★★
()
Ответ на: комментарий от ms-dos32

скачай исходники

Тема про то, как можно было бы обойтись без перекомпиляции

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

Так вот откуда нестабильё на арче...

Нестабильё на арче происходит исключительно из кривых рук и неумения читать. Доказано ЛОРом.

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

Тут тоже можно руками, но ТСу этого не надо :}

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

через USE

USE-флаги — полезная штука, но сами по себе порождают нехилую такую прибавку сложности к системе управления пакетами. И тут вопрос неоднозначный, что лучше: усложнять всю систему управления пакетами или руками пересобрать несколько пакетов по необходимости. Учитывая, что у меня в системе пакетов, собранных с опциями ./configure, отличными от дефолтных в PKGBUILD, все пара штук, очевидно, что лично мне система USE-флагов не нужна.

geekless ★★
()

Существует бинарный Quake II. Он поддерживает OpenGL. Но libGL в системе может и не быть, а игра будет запускаться и работать. Как они это сделали - не понимаю.

> Правда, дистрибутивы предлагают возможность перекомпилировать, но это неудобно

Если бы разработчики программ предлагали для загрузки не только RPM и DEB, но и SRPM и DEB-SRC, то их программы работали бы на любой системе с любыми версиями библиотек, а зависимости выбирал бы пользователь. И всё это даже не открывая консоль.

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

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

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

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

Они, кажется, оставили software mode и могут кинуть libGL.so прямо в папку с бинарниками игры.

ms-dos32
()
Ответ на: комментарий от ZenitharChampion

Если бы разработчики программ предлагали для загрузки не только RPM и DEB, но и SRPM и DEB-SRC, то их программы работали бы на любой системе с любыми версиями библиотек, а зависимости выбирал бы пользователь. И всё это даже не открывая консоль.

Т.е. ты предлагаешь компилировать пакет при установке? Тогда зачем вообще париться с RPM, проще генту или лунар сразу поставить.

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

Вот в mplayer не могут сделать так, что DirectFB не используется, а без его библиотеки программа не запускается. А они вот смогли сделать так, что если OpenGL не используется, а без его библиотеки программа запускается.

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

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

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

А они вот смогли сделать так, что если OpenGL не используется, а без его библиотеки программа запускается.

Ну так у них же в рантайме можно переключать рендерящий движок. Через dlopen, да.

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

Генту консольная, а я про компиляцию без консоли.

Пфф. Привязать в файловом менеджере ебилды к обработчику, который будет открывать терминал и запускать в нём сборку — это такая сложная задача?

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

Генту консольная, а я про компиляцию без консоли.

графическая морда к emerge?

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

>> Генту консольная, а я про компиляцию без консоли.

Пфф. Привязать в файловом менеджере ебилды к обработчику, который будет открывать терминал и запускать в нём сборку — это такая сложная задача?

Жду когда кто-нибудь сделает.

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

Ну, в данном случае много чего переписывать придётся. И не нужно это. Ты место на харде экономишь?

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

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

Нет, ничего плохого в этом не вижу. Просто поинтересовался, каковы твои мотивы всё взять и переписать.

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

всё взять и переписать.

Зачем всё? Сравнительно немного. Как будет быстрый интернет, загружу исходники mplayer и займусь вопросом.

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

почти все вручную собираю

Ещё один Ъ-неосилятор ABS. Попробуй, это то же твоё «вручную», только ничего не поломаешь и легко снесёшь потом.

CYB3R ★★★★★
()

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

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

да, это плохо, ты тратишь свое время на ерунду.

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

почему бы просто не поставить генту

Компиляция на нетбучном атоме - долгое занятие

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