CODEWITHSUNDEEP
cdllcmake
jakebird451
jakebird451

Reputation: 2348

Compiling a DLL using C

I am trying to compile a simple DLL using strictly C. The code for the entire test library is shown below:

#include <stdio.h>

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

The library is meant to be a simple proof of concept which is built using CMake as provided by CLion with the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.12)
project(test_lib C)

set(CMAKE_C_STANDARD 99)

add_library(test_lib SHARED library.c)

The DLL was built so I tried testing it with node-ffi and got Error: Dynamic Linking Error: Win32 error 126. Taking a step back from node-ffi, I put my newly created DLL in the apparently unanimously recommended debugging tool for DLLs: Dependency Walker. And it appears that the DLL I built has errors. Specifically:

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

Dependency Walker did however find that I am exporting the symbol hello. I am basing this on the fact that hello is listed with an entry point when I examine the root DLL in Dependency Walker. It shows up in the bottom of the two right panes in Dependency Walker with nothing in the top most pane. The only item in Dependency Walker's bottom pane for symbol exploration looks something like:

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

Where the [C ] is a grayish color (if this means anything to anyone).

I am not sure what I am missing to cause this DLL to have faulty exported dependencies/symbols.

Upvotes: 0

Views: 240

Answers (1)

jakebird451
jakebird451

Reputation: 2348

As it turns out, I was building for the wrong architecture. I was building for x86 with previous attempts (with my machine using an Intel processor). After all these attempts failing, I tried using this DLL in Python using ctypes. The error ctypes provided after loading in the DLL via CDLL('lib_test.dll') was much more elaborate, not only explaining the mismatched architecture, but which one my machine was expecting. In my case, it was x86-amd64.

Makes sense now that my DLL could not find those libraries. The DLL was attempting to fetch MSVC++ runtime libraries not installed since they are for a completely different architecture.

Upvotes: 1

Related Questions