1.4. Сборка динамической библиотеки из командной строки

1.4. Сборка динамической библиотеки из командной строки

Проблема

Вы хотите использовать свои инструменты командной строки для сборки динамической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.2.

Решение

Выполните следующие шаги.

1. Используйте компилятор для компиляции исходных файлов в объектные файлы. Если вы используете Windows, то для определения макросов, необходимых для организации экспорта символов динамической библиотеки, используйте опцию -D. Например, чтобы собрать динамическую библиотеку из примера 1.2, вы должны определить макрос GEORGERINGO_DLL. Если вы собираете библиотеку, написанную кем-то другим, то макросы, которые требуется определить, должны быть описаны в инструкции по установке.

2. Используйте компоновщик для создания из объектных файлов, созданных на шаге 1, динамической библиотеки.

Основные команды для выполнения первого шага приведены в табл. 1.8 Вы должны соответственно изменить имена входных и выходных файлов. Команды для выполнения второго шага приведены в табл. 1.11. Если вы используете инструментарий, который поставляется как со статическим, так и с динамическим вариантами библиотек времени исполнения, укажите компилятору и компоновщику использовать динамический вариант, как описано в рецепте 1.23.

Табл. 1.11. Команды для создания динамической библиотеки libgeorgeringo.so, libgeorgeringo.dll или libgeorgeringo.dylib

? CodeWarrior 10.0 для Mac OS X будет содержать динамический вариант своих библиотек. При сборке libgeorgeringo.dylib следует использовать именно их. (См. рецепт 1.23.)

Например, чтобы скомпилировать исходные файлы из примера 1.2 в объектные файлы с помощью компилятора Borland, предполагая, что директория, в которой находятся инструменты Borland, включена в переменную PATH, перейдите в директорию georgeringo и введите следующие команды.

> bcc32 -с -a -WR -о george.obj george.cpp

george.cpp:

> bcc32 -c -q -WR -o ringo.obj ringo.cpp

ringo.cpp:

> bcc32 -c -q -WR -DGERORGERINGO_DLL -o georgeringo.obj georgeringo.cpp

georgeringo.cpp:

Здесь опция компилятора -WR используется для указания того, что применяется динамический вариант рабочей библиотеки. Эти три команды сгенерируют объектные файлы george.obj, ringo.obj и georgeringo.obj. Затем введите команду:

> bcc32 -q -WD -WR -elibgeorgeringo.dll george.obj ringo.obj georgeringo.obj

Она сгенерирует динамическую библиотеку libgeorgeringo.dll. Наконец, введите команду:

> implib -с libgeorgeringo.lib libgeorgeringo.dll

Она сгенерирует библиотеку импорта libgeorgeringo.lib.

Обсуждение

То, как обрабатываются динамические библиотеки, в основном зависит от операционной системы и инструментария. С точки зрения программиста, два наиболее значительных отличия — это:

Видимость символов

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

В случае с большинством инструментариев для Windows, чтобы символ, определенный в динамической библиотеке, был доступен коду, использующему эту библиотеку, он должен быть явно экспортирован при сборке динамической библиотеки и импортирован при сборке исполняемого файла или другой динамической библиотеки, использующей эту библиотеку. Некоторые инструменты для Unix также предлагают такие возможности. Это верно для последних версий GCC для некоторых платформ, для Metrowerks на Mac OS X и для Intel для Linux. Однако в некоторых случаях нет никакого выбора, кроме как сделать все символы видимыми.

Передача библиотек компоновщику

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

Библиотеки импорта и файлы определения модулей

Библиотеки импорта, грубо говоря, являются статическими библиотеками, содержащими информацию, необходимую для вызова функций, содержащихся в DLL, во время исполнения. Нет необходимости знать, как они работают, надо только знать, как их создавать и использовать. Большинство компоновщиков создает библиотеки импорта автоматически при сборке DLL, но в некоторых случаях может оказаться необходимо использовать отдельный инструмент, который называется библиотекарь импорта (import librarian). В табл. 1.11 с целью избежать запутанного синтаксиса командной строки, требуемого компоновщиком Borland ilink32.exe, я использовал библиотекарь импорта Borland implib.exe.

Файл определения модуля, или файл .def — это текстовый файл, который описывает функции и данные, экспортируемые из DLL. Файл .def может быть написан вручную или автоматически сгенерирован каким-либо инструментом. Пример файла .def для библиотеки libgeorgeringo.dll показан в примере 1.5.

Пример 1.5. Файл определения модуля для libgeorgeringo.dll

LIBRARY LIBGEORGERINGO.DLL

EXPORTS

 Georgeringo @1

Экспорт символов из DLL

Имеется два стандартных метода экспорта символов из Windows DLL.

• Использование атрибута __declspec(dllexport) в заголовочных файлах DLL и сборка библиотеки импорта, предназначенной для применения при сборке кода, использующего эту DLL.

Атрибут __dеclspec(dllexport) должен указываться в начале объявления экспортируемой функции или данных, вслед за какими-либо спецификаторами сборки, и сразу за ним должно следовать ключевое слово class или struct для экспортируемого класса. Это проиллюстрировано в примере 1.6. Заметьте, что __declspec(dllexport) не является частью языка С++; это расширение языка, реализованное для большинства компиляторов для Windows.

• Создание файла .def, описывающего функции и данные, экспортируемые из динамической библиотеки.

Пример 1.6. Использование атрибута __declspec(dllexport)

__declspec(dllexport) int m = 3; // Экспортируемое определение данных

extern __declspec(dllexport) int n; // Экспортируемое объявление данных

__declspec(dllexport) void f(); // Экспортируемое объявление функции class

__declspec(dllexport) c { // Экспортируемое определение класса

 /* ... */

};

Использование файла .def имеет несколько преимуществ — например, он может позволить осуществлять доступ к функциям в DLL по номеру, а не по имени, что сокращает размер DLL. Он также устраняет необходимость запутанных директив препроцессора, таких как показанные в примере 1.2 в заголовочном файле georgeringo.hpp. Однако он также имеет и несколько серьезных недостатков. Например, файл .def не может использоваться для экспорта классов. Более того, можно забыть обновить свой файл .def при добавлении, удалении или изменении функций в вашей DLL. Таким образом, я рекомендую вам всегда использовать __declspec(dllexport). Чтобы изучить полный синтаксис файлов .def, а также научиться их использовать, обратитесь к документации по своему инструментарию.

Импорт символов из DLL

Как есть два способа экспорта символов из DLL, так есть и два способа импорта символов.

• В заголовочных файлах, включенных в исходный код, использующий DLL, используйте атрибут __declspec(dllimport) и при сборке этого кода передайте библиотеку импорта компоновщику.

• При сборке кода, использующего DLL, укажите файл .def.

Как и в случае с экспортом символов, я рекомендую вместо файлов .def использовать в вашем исходном коде атрибут __declspec(dllimport). Атрибут __declspec(dllimport) используется точно так же, как и атрибут __declspec(dllexport), обсуждавшийся ранее. Аналогично __declspec(dllexport) атрибут __declspec(dllimport) не является частью языка С++, а является расширением языка, реализованным для большинства компиляторов для Windows.

Если вы выбрали использование __declspec(dllexport) и __declspec(dllimport), вы должны убедиться, что при сборке DLL использовали __declspec(dllexport), а при компиляции кода, использующего эту DLL, использовали __declspec(dllimport). Одним из подходов является использование двух наборов заголовочных файлов: одного для сборки DLL, а другого для компиляции кода, использующего эту DLL. Однако это неудобно, так как сложно одновременно сопровождать две отдельные версии одних и тех же заголовочных файлов.

Вместо этого обычно используют определение макроса, который при сборке DLL расширяется как __declspec(dllexport), а в противном случае — как __declspec(dllimport). В примере 1.2 я использовал для этой цели макроопределение GEORGERINGO_DECL. В Windows, если определен символ GEORGERINGO_SOURCE, то GEORGERINGO_DECL раскрывается как __declspec(dllexport), а в противном случае — как __declspec(dllimport). Описанный результат вы получите, определив GEORGERINGO_SOURCE при сборке DLL libgeorgeringo.dll, но не определяя его при компиляции кода, использующего libgeorgeringo.dll.

Сборка DLL с помощью GCC

Порты GCC Cygwin и MinGW, обсуждавшиеся в рецепте 1.1, работают с DLL по-другому, нежели остальные инструменты для Windows. При сборке DLL с помощью GCC по умолчанию экспортируются все функции, классы и данные. Это поведение можно изменить, использовав опцию компоновщика --no-export-all-symbols, применив в исходных файлах атрибут __declspec(dllexport) или используя файл .def. В каждом из этих трех случаев, если вы не используете опцию --export-all-symbols, чтобы заставить компоновщик экспортировать все символы, экспортируются только те функции, классы и данные, которые помечены атрибутом __declspec(dllexport) или указаны в файле .def.

Таким образом, инструментарий GCC можно использовать для сборки DLL двумя способами: как обычный инструментарий Windows, экспортирующий символы явно с помощью __declspec, или как инструментарий Unix, автоматически экспортирующий все символы[1]. В примере 1.2 и табл. 1.11 я использовал последний метод. Если вы выберете этот метод, вы должны в целях предосторожности использовать опцию --export-all-symbols — на тот случай, если у вас окажутся заголовки, содержащие __declspec(dllexport).

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

Опция -fvisibility в GCC 4.0

Последние версии GCC на некоторых платформах, включая Linux и Mac OS X, дают программистам возможность более тонкого управления экспортом символов из динамических библиотек: опция командной строки -fvisibility используется для указания видимости символов динамической библиотеки по умолчанию, а специальный атрибут, аналогичный __declspec(dllexport) в Windows, используется в исходном коде для изменения видимости символов по отдельности. Опция -fvisibility имеет несколько различных значений, но два наиболее интересных — это default и hidden. Грубо говоря, видимость default означает, что символ доступен для кода других модулей, а видимость hidden означает, что не доступен. Чтобы включить выборочный экспорт символов, укажите в командной строке -fvisibility=hidden и используйте атрибут visibility (видимость) для пометки символов как видимых, как показано в примере 1.7.

Пример 1.7. Использование атрибута visibility с опцией командной строки -fvisibility=hidden

extern __attribute__((visibility("default"))) int m; // экспортируется

extern int n; // не экспортируется

__attribute__((visibility("default"))) void f(); // экспортируется

void g(); // не экспортируется

struct __attribute__((visibility("default"))) S { }; // экспортируется

struct T { }; //не экспортируется

В примере 1.7 атрибут __attribute__((visibility("default"))) играет ту же роль, что и __declspec(dllexport) в коде Windows.

Использование атрибута visibility представляет те же проблемы, что и использование __declspec(dllexport) и __declspec(dllimport), так как вам требуется, чтобы этот атрибут присутствовал при сборке общей библиотеки и отсутствовал при компиляции кода, использующего эту общую библиотеку, и чтобы он полностью отсутствовал на платформах, его не поддерживающих. Как и в случае с __declspec(dllexport) и __declspec(dllimport), эта проблема решается с помощью препроцессора. Например, вы можете изменить заголовочный файл georgeringo.hpp из примера 1.2 так, чтобы использовать атрибут видимости, следующим образом.

georgeringo/georgeringo.hpp

#ifndef GEORGERINGO_HPP_INCLUDED

#define GEORGERINGO_HPP_INCLUDED

// определите GEORGERINGO_DLL при сборке libgeorgeringo

#if defined(_WIN32) && !defined(__GNUC__)

#ifdef GEORGERINGO_DLL

#define GEORGERINGO_DECL __declspec(dllexport)

#else

#define GEORGERINGO_DECL __declspec(dllimport)

#endif

#else // Unix

# if defined(GEORGERINGO_DLL) && defined(HAS_GCC_VISIBILITY)

# define GEORGERINGO_DECL __attribute__((visibility("default")))

# else

#define GEORGERINGO_DECL

#endif

# endif

// Печатает "George, and Ringo "

GEORGERINGO_DECL void georgeringo();

#endif // GEORGERINGO_HPP_INCLUDED

Чтобы заставить это работать, вы должны при сборке в системах, поддерживающих опцию -fvisibility, определить макрос HAS_GCC_VISIBILITY.

Видимость символов в Metrowerks для Mac OS X

Metrowerks для Mac OS X предоставляет несколько опций для экспорта символов из динамической библиотеки. При использовании IDE CodeWarrior вы можете использовать файл экспорта символов, который играет роль файла .def в Windows. Вы также можете экспортировать все символы с помощью опции -export all, что при сборке из командной строки является поведением по умолчанию. Я рекомендую метод, использующий для пометки в вашем исходном коде экспортируемых функций #pragma export, и указание в командной строке -export pragma при сборке динамической библиотеки. Использование #pragma export иллюстрируется в примере 1.2: просто вызовите #pragma export on в ваших заголовочных файлах сразу перед группой функций, которые требуется экспортировать, а сразу после нее — #pragma export off. Если вы хотите, чтобы ваш код работал с инструментарием, отличным от Metrowerks, вы должны поместить обращения к #pragma export между директивами #ifdef/#endif, как показано в примере 1.2.

Опции командной строки

Давайте кратко посмотрим на опции, использованные в табл. 1.11. Каждая строка команды определяет:

• имя (имена) входного файла (файлов): george.obj, ringo.obj и georgeringo.obj;

• имя создаваемой динамической библиотеки;

• в Windows имя библиотеки импорта.

Кроме того, компоновщик требует опции, которая говорит ему создать динамическую библиотеку, а не исполняемый файл. Большинство компоновщиков используют опцию -shared, но Visual C++ и Intel для Windows используют -dll, Borland и Digital Mars используют -WD, a GCC для Mac OS X использует -dynamiclib.

Несколько опций в табл. 1.11 способствуют более эффективному использованию динамических библиотек во время выполнения. Например, некоторым компоновщикам для Unix требуется с помощью опции -fPIC сгенерировать независимый от положения код (position- independent code) (GCC и Intel для Linux). Эта опция приводит к тому, что несколько процессов смогут использовать единственную копию кода динамической библиотеки. На некоторых системах отсутствие этой опции приведет к ошибке компоновщика. Аналогично в Windows опция компоновщика GCC --enable-auto-image-base снижает вероятность того, что операционная система попытается загрузить две динамические библиотеки в одно и то же место. Использование этой опции помогает ускорить загрузку DLL.

Большая часть других опций используется для указания вариантов рабочей библиотеки и описывается в рецепте 1.23.

Смотри также

Рецепты 1.9, 1.12, 1.17, 1.19 и 1.23.