Подключение dll к проекту Visual Studio 2010 (C++)

Question

[Михаил .]

Есть библиотека (*.dll), в которой реализованы функции. Файла lib к этой библиотеки нет, но есть заголовочный файл (*.h) с объявлениями функций. Необходимо получить доступ к этим функциям.

Пробовал сделать lib-файл с помощью программы: Implib.exe, но пишет ошибку (IM2603 — invalid .DLL file).

Каким способом можно обращаться к функциям этой библиотеки?

Answer 1

[kostik450]

Делаете так:
lib.exe /DEF:test.def /OUT:test.lib /MACHINE:IX86

В файле test.def нужно записать:
LIBRARY TEST
EXPORTS
testfunc@32 @1

Узнать, какие там цифры вместо @32 проще всего через ошибки линковки (число в имени функции обычно равно числу ее параметров, умноженному на 4), а что там вместо @1 можно узнать через утилиту dumpbin.exe по списку экспортируемых из DLL функций.

Бывают DLL и без @32 — это зависит от того, как она была скомпилирована через __cdecl или через __stdcall
(это тоже легко устанавливается экспериментально)

Answer 2

[MikhailEdoshin]

Нужно сделать .lib-файл самостоятельно. Посмотрите, нет ли в комплекте с .dll файла .def. Если есть, то можно получить .lib с помощью

lib.exe /DEF:mylib.def mylib.dll

или

lib.exe /DEF:mylib.def /OUT:mylibname.lib mylib.dll

если нужно другое имя. В таком виде (dll + def), распространяется, например, sqlite3.

Если .def-файла нет, посмотрите, какие у вас символы в библиотеке через

dumpbin /exports mylib.dll

Если это практически те же имена, что и в заголовочном файле, значит, библиотека экспортирует символы в стиле С; это хорошо. Перечислите все нужные имена в командной строке:

lib.exe /EXPORT:mylib_func1 /EXPORT:mylib_func2 mylib.dll

(.def-файл, по сути, делает то же самое.) Единственное, я сейчас не помню, но к именам может спереди добавлятся подчеркивание. Я не уверен, нужно ли указывать имена с подчеркиванием или без.

Если там имен нет, значит, они отрезаны, функции можно определить только по порядковому номеру. Если вокруг них всякая муть, это C++, а муть означает закодированный тип параметров. Это все не очень хорошо, конечно, потому что соответствие номеров функциям не определить (разве что экспериментально), а стандарта на кодирование нет. Но технически создать .lib-файл можно, у опции /EXPORT полная сигнатура такая:

/EXPORT: entryname[= internalname][,@ ordinal[, NONAME]][, DATA]

То есть можно и переименовать функцию, и по номеру ее выбрать, и данные экспортировать. Но это на крайний случай.

lib.exe обычно не в PATH, из обычной командной строки не найдется, но в группе инструментов Visual Studio должно быть что-то вроде «Command Prompt» — он открывает консоль и добавляет нужные пути в PATH, так что инструменты командной строки становятся доступными.

Ссылки: dumpbin, lib.

Comments

[kostik450]

Добавлю, что если DLL содержит функции не в Си стиле, тогда можно прописать в .DEF через равно нужную нам функцию в Си стиле, убрав тем самым манглинг. Например:
@GetRandomNumbers$qipci = _GetRandomNumbers@12 @1

[MikhailEdoshin]

Да, тут у них даже в чем-то удобная система. Лично, правда, пользоваться не приходилось, не знаю, насколько полезная.

[Михаил .]

Пример того, что у меня выводит dumpbin и то что прописано в заголовочном файле (*.h):
void waitForData(int delayMs=0); == _ZN8Novorado10Parktronic11waitForDataEi
string libraryVersion() const; == _ZNK8Novorado10Parktronic14libraryVersionEv

[Михаил .]

Novorado — это namespace, Parktronic — класс, принадлежащий Novorado.

[MikhailEdoshin]

Ну вот Ei — это тип параметра int, а Ev — void. Но, по-моему, это не Microsoft'овский компилятор. Что-то даже с примерным описанием разных схем name mangling трудно сказать, чем это собрано. Вроде похоже на GCC, но не совсем.

Беда в том, что микрософтовские инструменты этого не поймут, потому как по тем же объявлениям будут искать функции с другим (своим) стилем name mangling. Добро пожаловать в C++ :) Единственный вариант, который можно попробовать — переопределять имена. Т. е. делать .lib так:

lib.exe /EXPORT:<имя в MS-стиле>=<реальное имя> mylib.dll

Попробуйте сначала с одной простой функцией. Чтобы выяснить имя в MS-стиле, можно написать свою (пустую) реализацию этой же библиотеки, скомпилировать ее в Visual Studio, и посмотреть, что выходит. Ну или аналитическим путем.

[Михаил .]

Да, узнал, что эта библиотека была написана на GCC (windows, minGW). Попробую переопределять имена, как Вы пишете. спасибо за помощь :) я так понял надо будет def — файл подсунуть MinGW, т.к. в нем была написана dll?

[MikhailEdoshin]

Вы знаете, скорее всего, ничего не выйдет. Может быть, конечно, что-то и выйдет, но шансы небольшие. Проблема в том, что библиотека экспортирует непосредственно С++ символы. У C++, в отличие от C не стандартизован ABI (application binary interface) и разные компиляторы реализуют его по-разному. То есть когда код, скомпилированный MS-компилятором, получит объект из кода, скомпилированного MinGW, очень может быть, что внутренняя его структура будет не такой, которую предполагает MS компилятор. Хотя объявления у объектов вроде бы одни и те же. Соответственно, работать с ним он не сможет.

Вроде бы Borland C++ в свое время озаботился тем, чтобы его C++ ABI совпадал с MS; в результате его C++ DLL можно было использовать с MS-продуктами и наборот. Что до GCC, у него даже между версиями ABI не совпадает. Добро пожаловать в C++, v2 :)

То есть даже если побороть name mangling, толку это не даст. Вариант только перекомпилировать dll под Visual Studio. Или на mingw сделать оболочку, чтобы завернуть C++ в обычный C.

[MikhailEdoshin]

А на вопрос-то я и не ответил: def-файл нужен для lib.exe, чтобы сделать .lib, обертку над DLL. См. первый пример в начальном ответе. MinGW, возможно, мог бы его использовать при линковке объектных файлов, но у вас не тот случай.

[Михаил .]

Вот что мне написал создатель библиотеки:
«Нужно сделать def файл (при помощи утилиты depends посмотрите экспорт имена в dll и руками пять строчек
напишите). Далее, сгенерить импорт библиотеку www.mingw.org/wiki/CreateImportLibraries
Задача встает достаточно часто когда разные компиляторы нужно состыковывать.»

Кстати, а по поводу C vs. C++ — если при вызове функций из библиотеки прописывать " extern «C» ", все равно толку не будет?

[MikhailEdoshin]

Если extern "C" не прописан, сейчас уже бессмысленно его прописывать. Это инструкция компилятору экспортировать одно только имя функции как оно есть (добавив только _ спереди) и не засовывать туда типы арументов и результата, чтобы можно было различать перегруженные функции. Если это не сделано при компиляции (а это не сделано), то имена уже не такие. Кроме того, у вас тут еще и классы имеются — их вообще нельзя в стиле С экспортировать. (Если нужно работать с С++ классом из С, обычно приходится писать раздельные заголовки, объявляя класс как структуру, давая другие сигнатуры функций — что-то вроде такого.)

Я несколько сомневаюсь, что автор библиотеки дает вам правильный совет. Хотя раз он так уверенно говорит, вдруг у него есть и C-интерфейс? Посмотрите, может быть в заголовочном файле уже есть extern "C", а среди невнятных имен, которые выдает dumpbin, есть называния таких функций? Если так, то да, эти имена вы сможете подцепить через def-файл и ссылка которую он приводит, как раз в тему.

Но если этого нет, то я очень удивлюсь, если проблема вдруг решится с помощью def-файла. Вот, например, страничка MinGW, описывающая, как создать DLL. Обратите внимание, что они используют extern "C" там, где могут, что пишут далее, что функция, не объявленная таким образом и C++ класс не будут доступными при вызове из другой среды (например, MS VC++):

The important and often overlooked consequence of this is that from the above DLL only the functions hello(const char *) and Double(int) are seamlessly callable from e.g. MS VC++ while CppFunc(void) is not (assuming the DLL is created by MinGW).

A similar statement goes for C++ classes exported in a DLL, i.e. for the class MyClass. For further reading search the Web for the keyword «ABI» and possible in conjunction with «C++».

Обратите внимание на «assuming the DLL is created by MinGW» — подразумевается, что если DLL будет скомпилирована MS VC++, то функция и класс будут доступны. Или, как они далее советуют, можно либо навертеть COM-объект, либо создать обертку в C-стиле:

A way to circumvent this problem is either using COM or create C-style wrapper functions to encapsulate the C++ ABI.

Answer 3

[zed91]

Объявляете указатель на функцию (такую как в h-нике), и переменную такого типа. Подгружаете библиотеку (LoadLibrary) Потом получаете адрес функции из библиотеки в помощью функции «GetProcAddress», и присваиваете этот адрес переменной типа указателя на функцию. Теперь функцию можно вызывать. Механизм называется динамическая подгрузка библиотеки. Примерно так:

typedef int (__stdcall somefuncptr*) (int, int); //по поводу этой строки не уверен

somefuncptr somefunc;

somefunc = GetProcAddress(«dllfuncname»);

int someval = somefunc(5, 10);

Answer 4

[Михаил .]

Спасибо, кто уже ответил! Сейчас буду экспериментировать. По итогам отпишусь.

Answer 5

[xanep]

А вы динамически подгружать библиотеку не хотите? Как zed91 написал.