Skip to content

Home Программирование Взаимодействие библиотек
Взаимодействие библиотек

Бывают случаи, когда динамическая библиотека сама компонуется с другой библиотекой. В этом нет ничего необычного. Такие зависимости между библиотеками можно увидеть при помощи программы ldd. Даже библиотека libmyenv.so из предыдущего раздела автоматически скомпонована со стандартной библиотекой языка С:

$ ldd libmyenv.so 
linux-gate.so.l =>(OxffffeOOO) 
libc.so.6 => /lib/libc.so.6 (0x40019000) 
/lib/ld-linux.so.2 (0x80000000)

Статические библиотеки не могут иметь таких зависимостей, но это не мешает им участвовать в создании динамических библиотек.

Рассмотрим практический пример создания динамической библиотеки с использованием других библиотек. Для этого нужно создать четыре исходника (по одному на каждую библиотеку и еще один — для исполняемой программы), что иллюстрируют листинги

Исходный файл first.c

#include <stdio.h> 
#include  "common.h"
void do_first   (void) 
{
printf   ("First library\n"); 
}

Исходный файл second.с

#include <stdio.h> 
#include  "common.h"
void do_second  (void) 
{
printf   ("Second library\n"); 
}

Исходный файл third.с

# include "common.h"
void do_third (void) 
{
do_first () ; do_second (); 
}

Программа program.с

#include  "common.h"
int main  (void) 
{
do_third  {};
return 0; 
}

Общий для всех файл coromon.h содержит объявления библиотечных функций.

Общий файл common.h

#ifndef COMMON_H 
#define COMMON_H
void do_first (void); 
void do__second (void); 
void do_third (void);
#endif

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

Файл Makefile

program: program.с libthird.so
gcc -о program program.с -L. -1third \ -Wl,-rpath,.
libthird.so: third.о libfirst.so libsecond.a
gcc -shared -o libthird.so third.о -L. \
-lfirst -lsecond -Wl,-rpath,.
third.о: third.с
gcc -с -fPIC third.с
libfirst.so: first.с
gcc -shared -fPIC -o libfirst.so first.с
libsecond.a: second.o
ar rv libsecond.a second.o
second.о: second.с
gcc -c second.c
clean:
rm -f program libfirst.so libsecond.a \ libthird.so *.o

Итак, make-файл содержит семь целевых связок. Рассмотрим каждую из них по порядку.

  1. Бинарник program — создается в один прием из исходного файла program.c с подключением динамической библиотеки libthird.so. Символ \ (обратный слэш) применяется в make-файлах для разбиения длинных строк.
  2. Динамическая библиотека libthird.so— получается в результате компоновки файла third.o с подключением динамической библиотеки libfirst.so и архива libsecond.a.
  3. Объектный файл third.o, содержащий позиционно-независимый код,— создается компиляцией исходного файла third.c с опцией -f pic.
  4. Совместно используемая библиотека libfirst.so — создается из исходного файла first.c. Компиляция и компоновка полученного позиционно-независимого объектного кода осуществляются в один прием.
  5. Статическая библиотека libsecond.a— создается путем архивирования единственного файла second.o.
  6. Файл second.o — получается в результате компиляции исходника second.c. Как уже отмечалось, для создания статических библиотек используются файлы, содержащие обычный объектный код с фиксированными позициями.
  7. Целевая связка clean — очищает проект, удаляя исполняемую программу, библиотеки и объектные файлы.

Теперь при помощи программы ldd проверим зависимости, образовавшиеся между библиотеками:

$ ldd libthird.so linux-gate.so.l =>(OxffffeOOO) 
libfirst.so => ./libfirst.so (0x40002000) 
libc.so.6 => /lib/libc.so.6 (0x4001c000) 
/lib/ld-linux.so.2 (0x80000000)

Как и ожидалось, библиотека libthird.so зависит от libfirst.so. Если вызвать программу ldd для исполняемого файла program, то можно увидеть образовавшуюся цепочку зависимостей полностью:

$ ldd program
linux-gate.so.l =>  (OxffffeOOO) 
libthird.so => ./libthird.so (0x40017000) 
libc.so.6 => /lib/libc.so.6 (0x40031000) 
libfirst.so => ./libfirst.so (0x4014e000) 
/lib/ld-linux.so.2 (0x40000000)

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

← Векторное чтение: readv()   Закрытие файла: close() →
Related Articles

Комментарии (0)

RSS feed Comments

Написать комментарий

smaller | bigger

busy
 

Регистрация




Top