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

1 - используют, причем дофига. Собственно любая программа, поддерживающая плагины.

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

На ум сразу приходит необходимость проверки версии либы при динамической загрузке. При установке с зависимостями это всё разрулится, а так самой софтине придётся сначала проверить, подходит ли нам установленная версия либы. Я могу ошибаться, но это не очень приятно для разработчиков.

потому что на сях это адъ, а на яве авторы большинства программ писать не умеют

Собственно любая программа, поддерживающая плагины.

Зачастую это питоны и прочее JIT.

Так потому что на явах с питонами такие штуки реализуются с гораздо меньшим pain in the ass чем на сях.

Где сильно растущая сложность?

просто к каждой части функционала добавляется функция-инициализатор.

и объём кода возрастает в 2 раза

dlopen, dlsym, dlclose - такой ужас?

Правда еще требуется создать указатели на функции, но это совсем несложно, тем более, что за 30 (или сколько там?) лет существования разделяемых библиотек в unix наверняка написали скрипт, ищущий использование функций из библиотеки, и создающий файл с указателями.

Вот обновил ты libхз, и половина системы отвалилась. Запускаешь revdep-rebuild, и он ВНЕЗАПНО ни фига не находит, ибо всё отвалившееся не слинковано с либой, а подгружает её в рантайме при запуске.

Тебе оно надо?

Где сильно растущая сложность?

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

Плюс сложности в тестировании всевозможных комбинаций, перенос многих глюков из compile time в runtime и много чего еще.

Подгрузка в рантайме точно так же использует ld.so, что и подгрузка при запуске программы, просто производится не при старте, а во время исполнения.

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

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

Я сам в ужасе. Из всех программ, которые я знаю, это используют только VLC, Wine и проприетарное ПО. В итоге скомпилируешь бинарник, а он только у меня и запустится. Особенно если это приложение для KDE.

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

Не во всех сборочных системах это пишется легко. Но вот с большим тестированием не соглашусь — нет причин для таких выводов.

Это легко решается - при динамической подгрузке, если не подгрузилось -

printf("Имя либы not found\n");

Я даже открою секрет - то, что ты называешь «слинкован» - на самом деле та же самая динамическая подгрузка, но на стадии запуска программы.

А по поводу ldd, загляни в его код, скорее всего ты будешь _очень_ удивлен.

Зачастую это питоны и прочее JIT.

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

dlopen, dlsym, dlclose - такой ужас?

Это проблемы при пакетировании.

Это проблемы при пакетировании ментейнером, слабо знающим кодовую базу

fixed

на каждой платформе свои особенности работы с динамическими библиотеками, где-то dlopen, dlsym, dlclose, а где-то LoadLibrary, GetProcAddress :)

Проще, когда это всё разруливается системой сборки, а не в рантайме

просто к каждой части функционала добавляется функция-инициализатор.

Откуда авторам программ знать все диапазоны совместимых версий либ? Тут уж лотерея заглючит/не заглючит.

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

враньё, у дебиана из бинарных дистров чуть ли не меньше всего _обязательных_ зависимостей, это не федора, в которой ещё совсем недавно kde тянул гномолибы

В кедах почти всё - плагины

[kosyak@knetbook ~]$ ls -ll /usr/lib/kde4 | wc -l
886

Это ужас для source-based дистрибутивов а-ля Gentoo, где такое должно разруливаться USE-флагами.

на яве

Динамическая подгрузка классов из jar-файла — тот еще цирк.

dlopen, dlsym, dlclose - такой ужас?

Это не кроссплатформенно.

по твоему сложить 2 и 2 это цирк?

Все проектные решения должны быть по возможности статическими.

/thread

Покажите мне код.

сорцы urlclassloader`а надеюсь ты сам найдешь

Потому что сложность разработки растёт. Если у тебя десяток библиотек, то в каждом спорном месте нужно проверить 10! комбинаций в рантайме. Зачем эти сложности, если можно просто потребовать библиотеку? Если программа запущена, значит библиотеки загружены.

FF и компания, подгружающие libflashplayer.so на лету

Это не разделяемая библиотека, а плагин.

Все проектные решения должны быть по возможности статическими.

Тебе сюда: Как побороть ужас зависимостей в Linux? Может сделать систему полностью статической?
:-)

А ты думаешь, что если в системе внезапно окажется несовместимая либа, то загрузка при старте чем-либо поможет?

Type: DYN (Shared object file)

Не важно:
$ locate libflashplayer.so
/usr/lib/browser-plugins/libflashplayer.so

Ну и:

$ readelf -a /usr/lib/browser-plugins/libflashplayer.so | grep SONAME
0x0000000e (SONAME) Library soname: [lib_plugin.so]

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

Зачем?

Последовательно загружаем те библиотеки, которые указаны в конфиге, а если не грузятся - выдаем ошибку.

Wiki:

In Unix operating systems, a soname is a field of data in a shared object file.

Т.е. soname есть только у shared object => всё, у чего оно есть, является shared object, а по русски, разделяемой библиотекой.

Но еслу тебе уж так неймется, то у libc6 указано libc.so.6. Всего лишь указание на то, как эта библиотека должна зваться, не более того, иногда помогающий при выборе версии библиотеки.

Последовательно загружаем те библиотеки, которые указаны в конфиге, а если не грузятся - выдаем ошибку.

Чем это отличается от того, что сейчас? И вообще, ты изобрёл http://en.wikipedia.org/wiki/Slackware#Dependency_resolution

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

Если бинарь требует конкретно libfontconfig.so.1 и libpng15.so.15, с которыми прога слинковалась при компиляции а потом удачно протестилась, то это увеличивает шансы что из кучи либ загрузятся именно эти версии. 100% гарантии нет но шансы выше.

Смотрим, например, сюда

@SuppressWarnings("unchecked")
public void addURL(URL u) throws IOException {
    URLClassLoader sysLoader = (URLClassLoader) ThisClass.class.getClassLoader();
    URL urls[] = sysLoader.getURLs();
    for (int i = 0; i < urls.length; i++) {
        if (urls[i].toString().equalsIgnoreCase(u.toString())) {
            return;
        }
    }
    Class sysclass = URLClassLoader.class;
    try {
        Method method = sysclass.getDeclaredMethod("addURL", parameters);
        method.setAccessible(true);
        method.invoke(sysLoader, new Object[] { u });
    } catch (Throwable t) {
        throw new IOException("Error, could not add URL to system classloader");
    }
}

А во всяких лиспах это делается простым

(load "someshit")

Увожываеый, у вас случайно нет некоторых нарушений работы мозга? Не? А то странно, вы нашли какойто наркоманский (ага) хак, хоты для решения задачи достаточно вызвать конструктор этого самого лоадера.

Но, я буду снисходителен к убогим 8)

Т.е. soname есть только у shared object => всё, у чего оно есть,
является shared object, а по русски, разделяемой библиотекой.

В каком месте «object» переводится как «библиотека» ? :-)

то у libc6 указано libc.so.6

Вот именно. «6» ! У настоящей разделяемой библиотеки в SONAME указывают версию ABI. Всё остальное - это лишь «нечто похожее на разделяемую библиотеку». В общем, матчасть изучайте.

И да, даже если у него поправить SONAME, по факту плагин этот не станет полноценной разделяемой библиотекой.

Чем тогда не устраивает slackware linux?

хоты для решения задачи достаточно вызвать конструктор этого самого лоадера

Может быть сейчас да, соглашусь. Но когда-то с этим были сложности :)

не было сложностей, сабжевый код - хак для тех чуидков кто хочет модифицировать classpath класслоадера в рантайме - это черевато спецэффектами.

а для кошерной загрузки создается класслоадер на кучку библиотек которые интересуют (а лучше по класслоадеру на плагин) и вуяля - зато не будет фееричных «can not cast someclas to someclass» и можно процессинг анотаций накрутить

Зачастую ненужный геморой. И не unix вей :]

dlopen, dlsym, dlclose - такой ужас?

Это не кроссплатформенно.

С чего бы?

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