|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 05 Aug 2002 10:13:54
To : Vickenty Fesunov
Subject : Re: stupid dependencies in RedHat 7.3
--------------------------------------------------------------------------------
>>> Vickenty Fesunov wrote:
VN>> Они и будут мягкими. Hет библиотеки - пакет ставится, но часть функций
VN>> работать не будет.
VF> Если он слинкован с той библиотекой, то его запустить будет нельзя:
VF> динамический линковщик его обругает.
По-моему, я четко определил контекст: никаких статических зависимостей.
Библиотеки подключает не ld.so, а dlopen в бинарнике. Потому и речь про
API для чтения ld.so.cache - ld.so и так это умеет без посторонней помощи.
VN>> Почему? Hа момент компиляции фиксирован API (включая ABI) вызова функции.
VN>> Определены имя функции, метод передачи параметров, метод возвращения
VN>> результата, с точностью до регистра, смещения в стеке, побитового формата.
VF> Ага, и мне в каждой проге таким геморроем заниматься? Hу уж нет. Способы с
VF> ума сойти и попроще есть.
Что ты назвал геморроем? Все сводится к нескольким простым вызовам -
1) Проверка хэндла библиотеки по имени или по ключу-константе
2) Поиск в ld.so.cache
3) Загрузка библиотеки
4) Поиск символа
Любая схема работы с плагинами это так или иначе умеет, а если сделать к тому
же, например, подгрузку всех библиотек при запуске, но без отказа грузиться
при частичном отсутствии - то это будет неплохим компромиссным вариантом.
С любым COM/CORBA/... ты получишь все равно ведь то же самое - явно придется
описывать интерфейсы, которые надо дергать, и явно их грузить.
Только они будут описываться другими именами, вот и вся разница.
(Hу и различие методов подключения - dlopen или отдельный процесс с общением
по пайпу или еще как-то - еще более усложнит картину.)
VN>> При том, что кто-то на момент сборки должен определить старшие номера
VN>> библиотек (как всем известно, смена старшего номера означает несовместимое
VN>> изменение API), использовавшихся для этой сборки, и сохранить их
VN>> куда-то - в бинарник, внешний конфиг, или еще куда-то. Если нет разумно
VN>> построенного доступа к ld.so.cache при запуске, то надо и полные пути
VN>> определить. Это может выполняться или вызываемым из makefile кодом,
VN>> или через rpm. Или еще как-то, но это не рассматриваем;)
VF> Ааа, так ежели так дело повернуть, так оно так и работает (насчет рпм не
VF> знаю, не пользуюсь). Hо если библиотека для пакета необязятельна, то при
VF> сборке, в 99% случаев она и не будет нужна, т.е. часть функций пропадет.
А вот как собирать пакет - уже проблема сборщика дистрибутива. Его задача,
чтобы были описаны нужные библиотеки. Поставит пакет, не поставит - сам будет
виноват в результате;)
VF> А я говорил про
VF> установку бинарника, которому надо, чтобы была такая-то библиотека, иначе он
VF> работать не будет (см. выше). А чтобы выборочно подключать библиотеки
VF> run-time, нужно чтобы для этого была создана инфраструктура.
Та инфраструктура совершенно крошечная, и очень многие держат ее сами в своих
программах. PAM видел изнутри? libpam вызывает нужные затычки, на что тратится
по сути всего пара строк. libc грузит NSS модули. И так далее...
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
