Д. Стефенс - C++. Сборник рецептов

Если вы выбрали использование __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 .

Порты 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] Экспорт символов с помощью __declspec(dllexport) иногда неправильно называют неявным экспортом . В примере 1.2 и табл. 1.11 я использовал последний метод. Если вы выберете этот метод, вы должны в целях предосторожности использовать опцию --export-all-symbols — на тот случай, если у вас окажутся заголовки, содержащие __declspec(dllexport).

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

В случае с Cygwin библиотека импорта для DLL xxx.dll обычно называется xxx.dll.a , в то время как в случае с MinGW она обычно называется xxx.a . Это просто вопрос соглашения.

Последние версии 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\n"

GEORGERINGO_DECL void georgeringo();

#endif // GEORGERINGO_HPP_INCLUDED

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

Последние версии компилятора Intel для Linux также поддерживают опцию -fvisibility .

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.