@yuriy0 you are correct. My process now is that I first start the Developer Command Prompt for Visual Studio 2019. When I then check the path of link.exe it is correctly located in
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\bin\Hostx86\x86\link.exe
For a long time I thought that the presence of the string
"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.22000.0\\ucrt"
means, that this version is required as a dependency is not correct since I do not have this path on my system.
When I use the resulting lib in a windows c++ program, I can correctly execute it. But for my use case I want to replace the kernel32.lib by a replacement that is provided by my realtime operating system supplier (Intervalzero RTX). Therefore, the symbols required by wasmer.lib should exactly match the provided symbols of this replacement kernel32.lib. This is not the case, since I get these linker errors:
Error LNK2001 unresolved external symbol __imp_ReleaseSRWLockExclusive WasmerTest C:\Users\schoetbi\source\repos\WasmerTest\WasmerTest\wasmer.lib(dynasmrt-a7e4b265862ce86a.dynasmrt.83b58e04-cgu.14.rcgu.o) 1
.. many more
Error LNK2001 unresolved external symbol GetFileInformationByHandle WasmerTest C:\Users\schoetbi\source\repos\WasmerTest\WasmerTest\wasmer.lib(same_file-45198a06d190a74d.same_file.397d7d37-cgu.6.rcgu.o) 1
So as I understand this, the problem is not what link.exe is used but what version of the kernel32.lib is used in the linker step.
I checked where kernrel32.libs are located on my system:
C:\Program Files (x86)\Windows Kits>rg --files | rg -i kernel32.lib
Then I renamed
10.0.19041.0_ in both the lib and the include folder and made
to regenerate wasmer.lib. But still the symbol requirements and the linker errors stayed the same.