Компиляция DLL с использованием C - PullRequest
0 голосов
/ 28 сентября 2018

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

#include <stdio.h>

__declspec(dllexport) void hello(void) {
    printf("Hello, World!\n");
}

Библиотека предназначена для того, чтобы быть простым доказательством концепции, построенной с использованиемCMake, предоставляемый CLion со следующим CMakeLists.txt:

cmake_minimum_required(VERSION 3.12)
project(test_lib C)

set(CMAKE_C_STANDARD 99)

add_library(test_lib SHARED library.c)

DLL была создана, поэтому я попытался протестировать ее с node-ffi и получил Error: Dynamic Linking Error: Win32 error 126.Сделав шаг назад от node-ffi, я поместил свою вновь созданную DLL в очевидно единодушно рекомендованный инструмент отладки для DLL: Dependency Walker .И кажется, что у DLL, которую я построил, есть ошибки.В частности:

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.

Однако Уокер зависимостей обнаружил, что я экспортирую символ hello.Я основываю это на том факте, что hello указан с точкой входа, когда я проверяю корневую DLL в Dependency Walker.Он отображается в нижней части двух правых панелей в Dependency Walker, и в верхней части самой панели ничего нет.Единственный элемент в нижней панели Dependency Walker для исследования символов выглядит примерно так:

E    | Ordinal    | Hint       | Function | Entry Point
-----+------------+------------+----------+------------
[C ] | 1 (0x0001) | 0 (0x0000) | hello    | 0x000010C8

Где [C ] - сероватый цвет (если это что-то значит для кого-либо).

Яне уверен, что мне не хватает, чтобы эта библиотека DLL имела ошибочные экспортированные зависимости / символы.

1 Ответ

0 голосов
/ 03 октября 2018

Как оказалось, я строил для неправильной архитектуры.Я строил для x86 с предыдущими попытками (на моей машине с процессором Intel).После неудачных попыток я попытался использовать эту DLL в Python, используя ctypes .Типы ошибок, предоставляемые после загрузки в DLL через CDLL('lib_test.dll'), были гораздо более сложными, объясняя не только несоответствующую архитектуру, но и то, что ожидала моя машина.В моем случае это было x86-amd64.

. Теперь имеет смысл, что моя DLL не может найти эти библиотеки.DLL пыталась получить библиотеки времени выполнения MSVC ++, не установленные, поскольку они для совершенно другой архитектуры.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...