Error LNK2001: unresolved external symbol __imp__LM_FindModule

[theberrigan]

I'm trying to create my own 32-bit DLL using static version of libmem-5.1.0 (without external libmem.dll), but every time I try to build the project a linking error appears:

dllmain.obj : error LNK2001: unresolved external symbol __imp__LM_FindModule
C:\Projects\CPPProjects\libmem-test\Release\libmem-test.dll : fatal error LNK1120: 1 unresolved externals

Reproduction steps:

1. Clone repo: https://github.com/theberrigan/libmem-test
   About project:
   • 32-bit DLL project
   • Used libmem-5.1.0-i686-windows-msvc-static-mt.tar.gz
   • In Release Configuration "Runtime Library" is set to "Multi-threaded (/MT)"
2. Open libmem-test.sln in Visual Studio.
3. Select Configuration "Release" and Platform "Win32".
4. Build project libmem-test.
5. The error described above will appear.

Project builds without errors with the shared version of libmem, but I need the static version.
Also I found this issue, but this is not exactly my case.

What I did:

• I tried to build the lib with default configuration according to build docs (using nmake).
• I tried to build it like this:

  cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DLIBMEM_ARCH=i386 -DLIBMEM_BUILD_STATIC=1
  nmake
  

• I tried to create a solution for VS2022 using Cmake GUI and build project with it.
• I tried different Runtime Libraries (/MT, /MTd, /MD, /MDd)

Versions:

• Windows 10 Pro 10.0.19045 build 19045 (22H2)
• Windows SDK 10.0.26100.0 (matches the WINSDK version from libmem 5.1.0 release)
• MSVC 14.44.35207 (matches the MSVC version from libmem 5.1.0 release)
• MS Build Tools 17.14.23.42201
• VS2022 17.14.18

[rdbo]

Did you add libmem.lib in the "Additional Dependencies" section of Visual Studio?
It's worth trying to add as well: user32.lib psapi.lib ntdll.lib and shell32.lib

[theberrigan]

Just tried it. Same error.

[ctrlaltferdinand]

Did you find a fix? @theberrigan running into the same issue..

[theberrigan]

Did you find a fix? @theberrigan running into the same issue..

Unfortunately no.

[rdbo]

I think the runtime for DLLs has to be /MD
So you need the static-md libmem build, and leave the runtime as /MD

[MY-Git-Li]

There might be an issue with the compilation.
When using static libraries, you cannot use __declspec(dllexport) or __declspec(dllimport) to demarcate functions.
The reasons are as follows:
Purpose of __declspec(dllexport) and __declspec(dllimport): These two are Microsoft VC++ extension keywords used for exporting and importing symbols in Dynamic Link Libraries (DLLs). dllexport is used in a DLL project to mark functions/classes that need to be exposed for external calls; the compiler generates an export table, and the linker places these symbols into the DLL’s export table. dllimport is used in client projects that call the DLL to mark symbols that need to be imported from the DLL; the compiler generates corresponding import code (e.g., via the import library .lib—note that this import library is different from a static library).
Then, the nature of static libraries (.lib): A static library is an archive collection of object files (.obj). When linking a static library, the linker directly copies the referenced .obj files from the static library into the final executable file (.exe/.dll). Static libraries themselves have no concept of "exporting/importing" symbols, because they are directly embedded into the target program and do not require runtime dynamic symbol resolution.

可能是编译出现了问题
当使用静态库时，函数不能使用__declspec (dllexport) 或者__declspec(dllimport)去描述函数
原因如下
__declspec (dllexport) 和__dllimport 的用途：这两个是微软 VC++ 的扩展关键字，用于 ** 动态链接库（DLL）** 的导出和导入符号。dllexport 是在 DLL 项目中标记要暴露给外部调用的函数 / 类，编译器会生成导出表，链接器会把这些符号放到 DLL 的导出表中；dllimport 是在调用 DLL 的客户端项目中标记要从 DLL 导入的符号，编译器会生成相应的导入代码（比如通过导入库.lib，注意这里的导入库和静态库不同）。
然后，静态库（static library，.lib）的本质：静态库是目标文件（.obj）的归档集合，当链接静态库时，链接器会把静态库中被引用的.obj 文件直接复制到最终的可执行文件（.exe/.dll）中。静态库本身并不存在 “导出 / 导入” 的概念，因为它是直接嵌入到目标程序中的，不需要运行时动态解析符号。

[rdbo]

There might be an issue with the compilation. When using static libraries, you cannot use __declspec(dllexport) or __declspec(dllimport) to demarcate functions. The reasons are as follows: Purpose of __declspec(dllexport) and __declspec(dllimport): These two are Microsoft VC++ extension keywords used for exporting and importing symbols in Dynamic Link Libraries (DLLs). dllexport is used in a DLL project to mark functions/classes that need to be exposed for external calls; the compiler generates an export table, and the linker places these symbols into the DLL’s export table. dllimport is used in client projects that call the DLL to mark symbols that need to be imported from the DLL; the compiler generates corresponding import code (e.g., via the import library .lib—note that this import library is different from a static library). Then, the nature of static libraries (.lib): A static library is an archive collection of object files (.obj). When linking a static library, the linker directly copies the referenced .obj files from the static library into the final executable file (.exe/.dll). Static libraries themselves have no concept of "exporting/importing" symbols, because they are directly embedded into the target program and do not require runtime dynamic symbol resolution.

While that is true and I had even merged a fix for that (#243), I think it broke the CI pipeline (which uses the static library) or something, so I reverted it afterwards and it started working again.
The GitHub Actions I have for testing on Windows uses the static library and seems to be working still, even without removing dllexport/dllimport: https://github.com/rdbo/libmem/actions/workflows/test-windows.yml
So I've kept if for the time being.