о необходимости создать архив. [8] Теперь можно подключать этот архив к программам с помощью флага
– ltest
компилятора
gcc
или
g++
, как описывалось в разделе 1.2.2, "Компоновка объектных файлов".
Обнаруживая в командной строке архив, компоновщик ищет в нем определения всех символических констант (функций или переменных), на которые дается ссылка в уже обработанных объектных файлах. Объектные файлы, содержащие определения этих констант, извлекаются из архива и включаются в исполняемый файл. В связи с тем что компоновщик просматривает архив один раз, архивные файлы нужно указывать в конце командной строки. Предположим, например, что имеются
два файла:
test.c
(листинг 2.7) и
app.c
(листинг 2.8).
8
Имеются и другие флаги, предназначенные для удаления файлов из архива и выполнения других операций над ним. Все они описаны на
man
– странице, посвященной команде
ar
.
Листинг 2.7. (test.c) Первый исходный файл
int f {
return 3;
}
Листинг 2.8. (app.c) Второй исходный файл
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.а
.
2.3.2. Совместно используемые библиотеки
Совместно используемая библиотека (известная также как динамически подключаемая библиотека) напоминает архив тем, что она представляет собой группу объектных файлов. Но между ними есть ряд важных различий. Самое основное из них заключается в том, что, когда совместно используемая библиотека подключается к программе, в исполняемый файл не включается код самой библиотеки: в нем присутствует лишь ссылка на библиотеку. Если с несколькими программами компонуется одна и та же библиотека, все они будут ссылаться на нее, но ни в одну из них она не будет включена. Так расшифровывается термин "совместное использование".
Второе важное отличие состоит в том, что совместно используемая библиотека — это не просто коллекция объектных файлов, из которых компоновщик выбирает требуемый для разрешения ссылки. В данном случае все объектные файлы, входящие в библиотеку, объединяются в единый объектный файл. Благодаря этому программы, компонующиеся вместе с библиотекой, всегда имеют доступ ко всему ее содержимому, а не только к одной конкретной части.
Чтобы создать совместно используемую библиотеку, нужно сначала скомпилировать составляющие ее объектные файлы с указанием опции
– fPIC
, например:
% gcc -с -fPIC test1.c
Опция
– fPIC
сообщает компилятору о том, что файл
test1
.o станет частью совместно используемой библиотеки.
Позиционно-независимый код
Аббревиатура PIC (Position-Independent Code) в названии опции расшифровывается как "позиционно-независимый код". Функции в совместно используемой библиотеке могут загружаться по разным адресам разными программами, поэтому код библиотеки не должен зависеть от адреса (или позиции), по которому она загружена. Все это никак не касается программистов, просто нужно не забывать указывать флаг
– fPIC
при компиляции файлов, которые могут включаться в совместно используемую библиотеку.
Затем следует объединить
объектные файлы в библиотеку:
% gcc -shared -fPIC -о libtest.so test1.o test2.o
Опция
– shared
заставляет компоновщик создать совместно используемую библиотеку, а не обычный исполняемый файл. Такие библиотеки имеют расширение
.so
. Подобно статическому архиву, имя библиотеки всегда начинается с префикса
lib
, указывающего на то. что файл является библиотекой.
Компоновка совместно используемой библиотеки аналогична компоновке архива. Например, следующая команда подключает к программе файл
libtest.so
, если он находится в текущем каталоге или одном из стандартных системных библиотечных каталогов:
% gcc -о app арр.о -L. ltest
Предположим, имеются оба файла:
libtest.а
и
libtest.so
. Каким образом компоновщик принимает решение? Он просматривает каждый заданный каталог (сначала те, что указаны в опции
– L
, затем стандартные) и, как только обнаруживает хотя бы один из файлов, тут же прекращает поиск. Если в найденном каталоге присутствует только один из файлов, он и выбирается. В противном случае выбор делается в пользу совместно используемой библиотеки, если явно не указано обратное. Отдать приоритет статическому архиву позволяет опция
– static
. Например, следующая команда подключит к программе архив
libtest.a
, даже если присутствует библиотека
libtest.so
:
% gcc -static -о app арр.о -L. – ltest
Команда
ldd
выводит список совместно используемых библиотек, подключенных к заданному исполняемому файлу. Все они должны быть доступны при запуске программы. Обратите внимание на то, что команда
ldd
сообщает о наличии дополнительной библиотеки:
ld-linux.so
. Она является частью механизма динамической компоновки в Linux.
Переменная LD_LIBRARY_PATH
Когда к программе подключается совместно используемая библиотека, компоновщик помещает в исполняемый файл ссылку на нее, но в этой ссылке указан не полный путь к библиотеке, а только имя файла. При запуске программы система сама находит библиотеку и загружает ее. По умолчанию система просматривает лишь каталоги
/lib
и
/usr/lib
. Если библиотека находится в другом каталоге, она не будет найдена и система откажется загружать программу.
Одно из решений заключается в компоновке программы с указанием флага