Разработка приложений в среде Linux. Второе издание - Майкл Джонсон

Точно так же используется и код каркаса (framework), который предлагает только интерфейс, а не реализацию. Например, каркас РАМ (Pluggable Authentication Modules — подключаемые модули аутентификации) предлагает обобщенный интерфейс для методов аутентификации с запросом и подтверждением, например, с участием имен пользователей и паролей. Сам процесс аутентификации осуществляется посредством модулей, а решение о выборе модуля аутентификации для отдельно взятого приложения принимается во время выполнения (а не во время компиляции) за счет обращения к конфигурационным файлам. Этот интерфейс имеет хорошее описание и является стабильным, а новые модули можно внедрять и использовать в любой момент без повторной компиляции каркаса или приложения. Каркас загружается в виде разделяемой библиотеки, а код в этой разделяемой библиотеке загружает и выгружает модули, обеспечивающие методы аутентификации.

27.1. Интерфейс dl

Процесс динамической загрузки заключается в открытии библиотеки, поиске любого количества символов, обработке любых возникающих ошибок и закрытии библиотеки. Все функции динамической загрузки объявляются в одном заголовочном файле, <dlfcn.h>, и определяются в libdl (чтобы воспользоваться функциями динамической загрузки скомпонуйте приложение с -ldl).

Функция dlerror() возвращает строку, описывающую самую последнюю ошибку, которая возникла в одной из трех других функций динамической загрузки:

const char * dlerror(void);

Каждый раз при возврате значения она очищает состояние ошибки. Если не будет создано другое состояние ошибки, она продолжит выполнение, чтобы вернуть NULL вместо строки. Объяснение этого необычного поведения можно найти в описании функции dlsym().

Функция dlopen() открывает библиотеку. Этот процесс включает поиск библиотечного файла, открытие файла и выполнение некоторой предварительной обработки. Переменные окружения и параметры, переданные функции dlopen(), определяют детали этого процесса.

void * dlopen(const char * filename, int flag);

Если filename является абсолютным путем (то есть начинается с символа /), то функции dlopen() не нужно производить поиск библиотеки. Это обычный способ применения функции dlopen() в коде приложения. Если filename является простым именем файла, то функция dlopen() произведет поиск библиотеки filename в перечисленных ниже местах.

• Набор каталогов, разделенных двоеточием, который определен в переменной окружения LD_ELF_LIBRARY_PATH, или, если ее не существует, в переменной LD_LIBRARY_PATH.

• Библиотеки, определенные в файле /etc/ld.so.cache. Этот файл генерируется программой ldcoding, регистрирующей каждую библиотеку, которую она находит в каталоге, указанном в /etc/ld.so.conf, во время ее выполнения.

• /usr/lib

• /lib

Если filename равен NULL, то функция dlopen() открывает экземпляр текущего исполняемого файла. Это полезно только в редких случаях. В случае сбоя функция dlopen() возвращает NULL.

Поиск файлов является простой частью работы функции dlopen(); разрешение символов является более сложной задачей. Существует два фундаментально разных типа разрешения символов: немедленный (immediate) и отложенный (lazy). При немедленном разрешении функция dlopen() разрешает все неразрешенные символы до возвращения результата; под отложенным разрешением подразумевается, что разрешение символов будет происходить по требованию.

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

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

Это особенно относится к тем случаям, когда вам необходимо, чтобы разделяемые объекты, зависящие от других разделяемых объектов, могли передавать некоторые свои символы. Если разделяемый объект А зависит от символа b в разделяемом объекте В, а В загружается после А, то отложенное разрешение b сможет быть выполнено только после загрузки объекта В, а до его загрузки — нет. Если написать код с немедленным разрешением, то вы сможете перехватить эту ошибку еще до того, как она сможет стать причиной возникновения проблем.

Здесь подразумевается, что загружать модули нужно всегда в обратном порядке по отношению к их зависимостям: если объект А зависит от объекта В в некоторых его символах, вы должны загрузить объект В до загрузки объекта А, и должны выгрузить объект А до выгрузки объекта B. К счастью, многие приложения с динамически загружаемыми разделяемыми объектами не имеют подобных взаимозависимостей.

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

Управление всеми этими действиями осуществляется через аргумент flags. Он должен иметь значение RTLD_LAZY для отложенного разрешения и RTLD_NOW для немедленного разрешения. Любое из этих значений может быть объединено битовым "ИЛИ" с RTLD_GLOBAL, чтобы разрешить экспортирование символов в остальные модули.

Если разделяемый объект экспортирует программу _init, то она будет выполняться до того, как функция dlopen() вернет результат.

Функция dlopen() возвращает дескриптор (handle) того разделяемого объекта, который она открыла. Это непрозрачный объектный дескриптор, который следует использовать только как аргумент для последующих вызовов функций dlsym() и dlclose(). Если разделяемый объект открывается несколько раз, функция dlopen() каждый раз будет возвращать один и тот же дескриптор, и с каждым новым вызовом счетчик ссылок будет увеличиваться на единицу.

Функция dlsym() производит поиск символа в библиотеке:

void * dlsym(void * handle, char * symbol);

handle должен представлять собой дескриптор, возвращенный функцией dlopen(), a symbol должен содержать строку с завершающим NULL, которая именует искомый символ. Функция dlsym() возвращает адрес определенного вами символа или NULL в случае возникновения неустранимой ошибки. Если вы будете знать, что NULL не является правильным адресом символа (например, при поиске адреса функции), можно выполнить проверку на наличие ошибок, посмотрев, возвращает ли она NULL. Однако в общем случае некоторые символы могут иметь нулевые значения и быть равными NULL. Тогда вам нужно будет узнать, не возвращает ли функция dlerror() ошибку. Поскольку функция dlerror() возвращает ошибку только один раз, возвращая после этого NULL, вы должны организовать свой код следующим образом.

/* удалить любое состояние ошибки, которое еще не было прочитано */

dlerror();

p = dlsym(handle, "this_symbol");

if ((error = dlerror()) != NULL) {

 /* обработка ошибки */

}

Так как функция dlsym() возвращает void *, вам необходимо использовать приведение типов, чтобы компилятор С не выдавал сообщений об ошибках. Если вы сохраняете указатель, возвращенный функцией dlsym(), сохраните его в переменной того типа, который вы хотите использовать, и выполните приведение типа во время вызова функции dlsym(). Не сохраняйте результат в переменной void *; вам придется выполнять приведение типов каждый раз во время ее использования.

Функция dlclose() закрывает библиотеку.

void * dlclose(void * handle);

Функция dlclose() проверяет счетчик обращений, который увеличивался на единицу при каждом повторном вызове функции dlopen(), и если он равен нулю, она закрывает библиотеку. Этот счетчик обращений позволяет библиотекам применять функции dlopen() и dlclose() для произвольных объектов, не беспокоясь о том, что код, в котором производится вызов, уже открыл какие-либо из этих объектов.