Марк Митчелл - Программирование для Linux. Профессиональный подход

#include

#include

#include

#include

char* read_from_file(const char* filename, size_t length) {

char* buffer;

int fd;

ssize_t bytes_read;

/* Выделяем буфер. */

buffer = (char*)malloc(length);

if (buffer == NULL)

return NULL;

/* Открываем файл. */

fd = open(filename, O_RDONLY);

if (fd == 1) {

/* Открыть файл не удалось. Освобождаем буфер

перед выходом. */

free(buffer);

return NULL;

}

/* Чтение данных. */

bytes_read = read(fd, buffer, length);

if (bytes_read != length) {

/* Чтение не удалось. Освобождаем буфер и закрываем файл

перед выходом. */

free(buffer);

close(fd);

return NULL;

}

/* Все прошло успешно. Закрываем файл и возвращаем буфер

в программу. */

close(fd);

return buffer;

}

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

Практически со всеми программами компонуется одна или несколько библиотек. К любой программе, использующей функции языка С (например, printf()или malloc()), подключается библиотека времени выполнения. Если у программы есть графический интерфейс, вместе с ней компонуются библиотеки функций работы с окнами. Когда программа обращается к СУБД, она делает это посредством функции библиотеки, предоставленной разработчиком данной СУБД.

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

Архив (или статическая библиотека) — это коллекция объектных файлов, хранящаяся в виде одного файла (он является примерным эквивалентом LIB-файла в Windows). Когда архив поступает на вход компоновщика, тот ищет в нем нужные объектные файлы, извлекает их и подключает к программе так, как если бы они были указаны непосредственно.

Архив создается посредством команды ar. Архивные файлы традиционно имеют расширение .a, а не .o, которое закреплено за отдельными объектными файлами. Вот как объединить файлы test1.oи test2.oв единый архив libtest.a:

% ar cr libtest.a test1.o test2.o

Флаги crсообщают команде arо необходимости создать архив. [8] Имеются и другие флаги, предназначенные для удаления файлов из архива и выполнения других операций над ним. Все они описаны на man -странице, посвященной команде ar . Теперь можно подключать этот архив к программам с помощью флага -ltestкомпилятора gccили g++, как описывалось в разделе 1.2.2, "Компоновка объектных файлов".

Обнаруживая в командной строке архив, компоновщик ищет в нем определения всех символических констант (функций или переменных), на которые дается ссылка в уже обработанных объектных файлах. Объектные файлы, содержащие определения этих констант, извлекаются из архива и включаются в исполняемый файл. В связи с тем что компоновщик просматривает архив один раз, архивные файлы нужно указывать в конце командной строки. Предположим, например, что имеются два файла: test.c(листинг 2.7) и app.c(листинг 2.8).

int f() {

return 3;

}

int main() {

return f();

}

Теперь допустим, что файл test.oвключен вместе с другими объектными файлами в архив libtest.a. Тогда следующая команда не будет работать:

% gcc -о app -L. -ltest app.о

app.о: In function 'main':

app.о(.text+0x4): undefined reference to 'f'

collect2: ld returned 1 exit status

Как следует из сообщения об ошибке, несмотря на то что файл libtest.асодержит определение функции f(), компоновщик не нашел ее. Это объясняется тем. что компоновщик анализирует свои аргументы последовательно, слева направо, просматривая архив сразу же, как только он встречается в командной строке. На тот момент компоновщик еще не знал, что в дальнейшем ему встретится ссылка на функцию f(). Если сделать небольшую перестановку, все заработает:

% gcc -о app арр.о -L. -ltest

Теперь наличие в файле app.оссылки на функцию f()заставляет компоновщик включить в программу объектный файл test.oиз архива libtest.а.

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

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

Чтобы создать совместно используемую библиотеку, нужно сначала скомпилировать составляющие ее объектные файлы с указанием опции -fPIC, например:

% gcc -с -fPIC test1.c

Опция -fPICсообщает компилятору о том, что файл test1.o станет частью совместно используемой библиотеки.

Аббревиатура PIC (Position-Independent Code) в названии опции расшифровывается как "позиционно-независимый код". Функции в совместно используемой библиотеке могут загружаться по разным адресам разными программами, поэтому код библиотеки не должен зависеть от адреса (или позиции), по которому она загружена. Все это никак не касается программистов, просто нужно не забывать указывать флаг -fPICпри компиляции файлов, которые могут включаться в совместно используемую библиотеку.