FAQ: Как подключить библиотеку на C/C++? Зачем файлы .h, .lib, .dll?

Этот вопрос довольно часто возникает у начинающих, а также у программистов, которые привыкли работать с языками, имеющими встроенную поддержку импорта из модулей (например, Delphi/Pascal).

В языке C исторически сложилось иначе. Чтобы подключить библиотеку к программе на языке C или C++, нужно выполнить два действия:

1. Включить в исходный текст заголовочные файлы библиотеки (.h или .hpp) директивой #include
2. Обеспечить, чтобы при сборке программы использовались соответствующие объектные файлы библиотеки (в зависимости от системы они могут иметь расширения .lib, .a, .o, .obj и т.д.) В зависимости от используемого компилятора это делается разными способами, например:
   – добавить файл(ы) в проект как объектные;
   – в MS Visual Studio: добавить имя файла в Linker->Input->Additional Dependencies (если файл в другом каталоге, путь добавить в Linker->General->Additional Library Directories);
   – при использовании make прописать файл в список файлов для линкера (обычно это LIBS= или т.п.).
   А если библиотека представлена в исходных текстах, надо просто добавить все нужные .c (.cpp) файлы в проект программы.

Файлы .lib должны быть совместимы с используемым компилятором и ОС. Поэтому к библиотеке может прилагаться несколько наборов файлов для разных сред.

Файлы .dll (динамическая библиотека Windows) не нужно указывать при компиляции, они используются при выполнении программы (о динамических библиотеках см. ниже).

В чём смысл этих действий, зачем нужны все эти разные файлы?

Файл заголовков (.h) нужен для того, чтобы компилятор мог распознать идентификаторы (имена макросов, типов, переменных, функций), которые определены в библиотеке. Специального средства для импорта имён в стандартном C нет, и для этого используется директива препроцессора #include, которая вставляет включаемый файл как исходный текст, как если бы он был написан вместо директивы #include.

В файлах .h идентификаторы объявляются, но не определяются (decalared but not defined), т.е. под переменные не выделяется пространство, а функции не имеют кода. Это достигается использованием ключевого слова extern для переменных, а для функций даются прототипы, например:

/* mylib.h */
extern int mylib_global_variable;
int mylib_function(int x, int y);

Если эти объявления включить через #include, то компилятор сможет скомпилировать .c файл, в котором упоминаются mylib_global_variable и mylib_function, например:

/* myprog.c */
#include "mylib.h"
int main(void)
{
mylib_global_variable = 1;
return mylib_function(mylib_global_variable, 2);
}

После компиляции получится объектный файл (например, myprog.o), причем в нём эти идентификаторы будут описаны как внешние. Но линкер не сможет собрать такую программу в готовый исполнимый файл, потому что для этих идентификаторов нет определений, т.е. есть имена, но нет "тела".
При попытке собрать программу будет выдано сообщение об ошибке "undefined external".

Теперь нужно, чтобы при сборке программы нашёлся объектный файл, в котором реализованы все эти переменные и функции. Допустим, у нас есть исходный текст библиотеки – например, такой:

/* mylib.c */
int mylib_global_variable = 0;
int mylib_function(int x, int y)
{
return x + y;
}

Тогда при его компиляции получится объектный файл, который можно соединить с нашей основной программой (включить оба .c файла в проект или makefile), и всё готово.

Если же библиотека уже скомпилирована отдельно, то нужно взять готовые объектные файлы (.lib или .a – это по сути контейнеры объектных файлов) и передать их линкеру.

Это в общих чертах всё, что касается статических библиотек, т.е. таких, код которых попадает в исполнимый файл основной программы.

О динамических библиотеках следует сказать отдельно. Динамическая библиотека отличается тем, что её код хранится в отдельном файле (Windows – .dll, в системах типа GNU/Linux и FreeBSD – .so) и загружается операционной системой при запуске программы, либо самой программой по мере надобности.

Рассмотрим оба способа на примере Windows.

Чтобы подключить динамическую библиотеку с загрузкой при запуске, используются файлы .h и .lib – точно так же, как в случае статической библиотеки. Просто в данном случае .lib файл содержит не сам код, а ссылки на импортируемые функции из DLL, так что после компиляции получается .exe файл, в котором есть ссылки на нужную DLL. Файл .dll при компиляции не нужен, зато нужен при запуске (в каталоге с .exe файлом, в системных каталогах Windows, в каталогах, перечисленных в переменной окружения PATH и т.д.).

Также можно загружать динамическую библиотеку "вручную" функциями LoadLibrary и GetProcAddress. Тогда .lib файл не нужен вообще, а .h включить обычно нужно (чтобы иметь описания типов и констант-макросов), но к функциям обращаться нужно будет не по именам из .h, а через указатели соответствующих типов, например:
/* ... */
typedef int (*my_funct_ptr_t)(int, int); /* тип указателя на функцию */
HINSTANCE h_dll;
my_func_ptr_t func;
int x = 1, y = 2, z;
h_dll = LoadLibrary("mylib.dll");
if (NULL == h_dll) return MY_ERROR_CANNOT_LOAD_DLL;
func = (my_func_ptr_t)GetProcAddress(h_dll, "mylib_function");
if (NULL == func) return MY_ERROR_FUNCTION_NOT_FOUND;
z = func(x, y);
/* ... */