Mazdaywik
commented
5 years ago Детали создания динамических библиотек
Задача состоит в том, чтобы для используемых компиляторов (Windows: BCC 5.5.1, Visual C++, GCC, Watcom; Linux: GCC) найти способ (а) получать библиотеку, из которой можно извлечь refalrts::NativeModule g_module, и (б) загрузить эту библиотеку. При этом способ должен ложиться в инфраструктуру компилятора.
При этом желательно минимизировать использование платформенно-зависимых средств компилятора.
Windows
На Windows библиотеки могут экспортировать только функции, переменные экспорту не подлежат. По крайней мере, я таких упоминаний не встречал. Поэтому для экспорта значения g_module нужно экспортировать функцию, возвращающую &g_module.
В качестве эксперимента требовалось экспортировать функцию вида:
int the_func(int x) {
return x * 100;
}При этом её имя должно быть доступно как "the_func" в GetProcAddress(). Путём экспериментов выяснилось, что разные компиляторы по разному декорируют имя для разных соглашений по вызову (__cdecl, __stdcall…), для экспорта функции используются разные директивы (__declspec(dllexport), __attribute__((dllexport))…), разные директивы используются для задания этих соглашений по вызову.
Альтернативный способ экспорта функций — использование .def-файлов. Синтаксис у него тоже различается в разных компиляторах, но можно выбрать минимальное общее подмножество, достаточное для экспорта одной функции.
В общем, опытным путём удалось экспортировать функцию в следующей форме:
#include <windows.h>
extern "C"
#ifdef __BORLANDC__
__declspec(dllexport)
#endif
int WINAPI the_func(int x) {
return x * 100;
}и .def-файл:
EXPORTS
the_func @1 ; the_funcОказалось, что передать .def-файл через командную строку bcc32 (версии BCC 5.5.1) нельзя. Нужно сначала компилировать в объектники, а потом явно вызывать линковщик. Но использование соглашения stdcall (задаваемое макросом WINAPI) обеспечивает необходимое декорирование имени (вернее, его отсутствие). Заметим, на других компиляторах использование __declspec(dllexport) + WINAPI приводит к другому декорированию (не помню, какому, давно ковырял).
Остальные компиляторы для Windows правильно понимают .def-файл в своей командной строке.
Командные строки получились следующие:
- BCC 5.5.1:
bcc32 -tWD -edlltest-bcc.dll dlltest.cpp - Visual C++:
cl /EHcs /LD dlltest.def /Fedlltest-vc.dll dlltest.cpp - GCC:
gcc -shared -Wl,--enable-stdcall-fixup dlltest.def -odlltest-gcc.dll dlltest.cpp - Open Watcom:
cl -W3 -passwopts:-wcd=13 -LD dlltest.def -Fedlltest-watcom.dll dlltest.cppВсе вышеперечисленные командные строки можно записать в виде:
〈префикс〉 〈имя-новой-dll〉 〈исходники〉причём имя .def-файла будет попадать в префикс. Так что командная строка прекрасно подходит для имеющейся архитектуры.
Импортирующий файл довольно очевиден:
#include <windows.h>
#include <stdio.h>
typedef int (WINAPI *callback_t)(int);
int main(int argc, char *argv[]) {
const char *dllname = ".\\dlltest";
HMODULE lib;
callback_t func;
int arg;
if (argc > 1) {
dllname = argv[1];
}
lib = LoadLibraryEx(dllname, NULL, 0);
if (! lib) {
printf("Can't load library\n");
return 1;
}
func = (callback_t) GetProcAddress(lib, "the_func");
if (func) {
arg = 42;
printf("call func(%d) = %d\n", arg, func(arg));
} else {
printf("Can't find symbol\n");
FreeLibrary(lib);
return 1;
}
FreeLibrary(lib);
printf("Success\n");
return 0;
}Linux
Под Линуксом возникла проблема.
На первый взгляд, проблем нет. В импортируемом файле просто объявляем нестатическую глобальную переменную, в импортирующем используем dlopen() + dlsym() для доступа:
int the_value = 42;#include <dlfcn.h>
#include <stdio.h>
int main(int argc, char *argv[]) {
const char *dllname = "./dlltest.so";
void *lib;
int *pvalue;
if (argc > 1) {
dllname = argv[1];
}
lib = dlopen(dllname, RTLD_NOW);
if (! lib) {
printf("Can't load library: %s\n", dlerror());
return 1;
}
pvalue = (int*) dlsym(lib, "the_value");
if (pvalue) {
printf("*pvalue = %d\n", *pvalue);
} else {
printf("Can't find symbol\n");
dlclose(lib);
return 1;
}
dlclose(lib);
printf("Success\n");
return 0;
}Но засада возникает при сборке:
all: run dlltest.so
./run ./dlltest.so
run: run.cpp
g++ -o $@ $+ -ldl
dlltest.so: dlltest.cpp
g++ -shared -fpic -o $@ $+Ключ -ldl, который подключает библиотеку с функциями dlopen(), dlsym()…, в командной строке должен быть последним. Т.е.
g++ -o run run.cpp -ldlработает, а
g++ -ldl -o run run.cppне работает.
Однако, Рефал-5λ сейчас поддерживает командную строку только такого вида:
〈префикс〉〈имя-целевого-файла〉〈дополнительные-флаги〉〈исходники〉где
〈префикс〉задаётся в--cpp-command-exeили--cpp-command-lib,〈имя-целевого-файла〉формируется компилятором на основе флага-oили имени первого исходника,〈дополнительные-флаги〉передаются опциями-Fи-f,〈исходники〉— исходники C++.
Места для передачи -ldl в конце просто нет.
Варианты:
- Расширить синтаксис
--cpp-command-???до строки видаg++ -o@EXE@ @FLAGS@ @SOURCES@ -ldl. С одной стороны, это идеально решит проблему с передачей опций, которые могут быть только в конце. С другой — затруднится раскрутка стабильной версии. Сейчас к префиксу, заданному вc-plus-plus.conf.*, можно в скрипте просто приписать имя исполнимого файла и исходники. Потом придётся чем-то парсить шаблон. - Добавить аналог флагов
-F/-f(или--cpp-command-???), которые будут добавляться в конец командной строки. Нужно будет добавлять новую опцию, которая не будет до следующей версии пониматься стабильной версией. - Перенести флаги в конец. Может быть, сейчас поможет, но потом всплывут флаги, которые наоборот, должны быть только в начале.
Все решения сомнительны.
Эта задача — подзадача для #76, частично относится к #87.
Цель
Необходимо реализовать генерацию и загрузку модулей типа N — библиотек .dll/.so.
Что уже есть
srefc-coreможет генерировать N-модули, поскольку они генерируются почти также, как и I-модули.srmake-coreтоже поддерживает генерацию N-модулей. Вроде как.srmake-coreумеет находить исходники для исполнимых и библиотечных модулей в разных папках.Этого всего уже немало и это неплохо.
Что надо сделать
.def-файлов компиляторов на Windows, вариантов декорирования имён и т.д.new/mallocв одном модуле, должен освобождатьсяdelete/freeв том же самом модуле — должна поддерживаться возможность безболезненной работы.dll-ок и модуля типа I, созданных разными компиляторами.Hashдинамическим модулем.(список может пополняться)