I'm compiling a kernel mode driver that uses the Microsoft Dmf framework (DmfK.lib)
After the last Visual Studio update some strange linker errors appeared :
EmulationTargetPDO.obj : error LNK2019: unresolved external symbol __stdio_common_vswprintf referenced in function _vsnwprintf_l
Utilities.lib(savedata.obj) : error LNK2001: unresolved external symbol __stdio_common_vswprintf
DmfK.lib(DmfUtility.obj) : error LNK2001: unresolved external symbol __stdio_common_vswprintf
EmulationTargetPDO.obj : error LNK2019: unresolved external symbol __stdio_common_vsprintf referenced in function _vsnprintf_l
DmfK.lib(DmfCore.obj) : error LNK2001: unresolved external symbol __stdio_common_vsprintf
DmfK.lib(Dmf_CrashDump.obj) : error LNK2019: unresolved external symbol __stdio_common_vsprintf_s referenced in function _vsprintf_s_l
Here's the software and kits versions I use (shown in VS "About" windows):
Microsoft Visual Studio Professional 2019 Version 16.10.0
Windows SDK 10.0.19041.685
Windows Driver Kit 10.0.19030.1000
The second strange thing is that I've downloaded and installed the WDK 10.0.19041.685 but VS still displays 10.0.19030.1000 ...
A similar problem can be found here : Linker error when compiling windows kernel mode driver x64 but it hasn't been solved.
Set this define before including any headers:
#define _NO_CRT_STDIO_INLINE
or add it to the compiler's command line:
-D_NO_CRT_STDIO_INLINE
We (Microsoft driver team) are looking into this issue to see about removing the need for such a workaround.
Related
I'm trying to make an installer for Windows with WiX. I'm following this tutorial.
I get the following error:
trunk\Setup\Product.wxs(12): error LGH
T0094: Unresolved reference to symbol 'WixUI:WixUI_InstallDir' in section 'Prod
uct:*'. [trunk\Setup.wixproj]
Here is my Product.wxs and my setup.build file.
Thanks!
I have a C++ Visual Studio 2010 project, which I can run in x64 mode. But I want to run it in x32 also.. So here I have a problem - this project uses a Matlab API, which I never met before. I have these errors:
1>ReadMatrix.obj : error LNK2001: unresolved external symbol _matOpen
1>ReadMatrix.obj : error LNK2001: unresolved external symbol _matGetVariable
1>ReadMatrix.obj : error LNK2001: unresolved external symbol _mxGetDimensions_730
1>ReadMatrix.obj : error LNK2001: unresolved external symbol _mxGetPr
1>ReadMatrix.obj : error LNK2001: unresolved external symbol _mxDestroyArray
1>ReadMatrix.obj : error LNK2001: unresolved external symbol _matClose
I looked in the Matlab folder(2011a) on the path
..\MATLAB\R2011a\extern\include, but found there only x64 files. What I should do?
You'll have to get hands on the 32bit libraries from a corresponding 32bit Matlab installation.
One possible simplification:
For compilation (not running) only, you do not necessarily need a full 32bit MATLAB installation, but only the library files (libmat, libmx, libmex).
This might simplify things if you'd e.g. like to compile the 32bit version for a colleague etc.
I've the same problem as Can't build Allegro 5 solution in MSVC 2012 but my project is x64 and I have Win8 x64 professional. And when I'm turn to Win32 everytging is ok. But when turn to x64 I have this:
1>------ Build started: Project: test_allegro, Configuration: Debug x64 ------
1>main.obj : error LNK2019: unresolved external symbol al_install_system referenced in function main
1>main.obj : error LNK2019: unresolved external symbol al_rest referenced in function main
1>main.obj : error LNK2019: unresolved external symbol al_map_rgb referenced in function main
1>main.obj : error LNK2019: unresolved external symbol al_create_display referenced in function main
1>main.obj : error LNK2019: unresolved external symbol al_destroy_display referenced in function main
1>main.obj : error LNK2019: unresolved external symbol al_flip_display referenced in function main
1>main.obj : error LNK2019: unresolved external symbol al_clear_to_color referenced in function main
1>D:\Biblioteki\Dropbox\studia\przedmioty\sem_3\aisdi\laboratorium\test_allegro\x64\Debug\test_allegro.exe : fatal error LNK1120: 7 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Any ideas? My project have to be x64...
I'm trying to create dll with 'yaml-cpp-0.3.0' under Visual Studio 8 2005 and getting linking error for 'INSTALL', 'run-tests'
Error 1 error LNK2019: unresolved external symbol "void __cdecl YAML::operator>>(class YAML::Node const &,class YAML::Binary &)" (??5YAML##YAXABVNode#0#AAVBinary#0##Z) referenced in function "public: class YAML::Binary const __thiscall YAML::Node::to(void)const " (??$to#VBinary#YAML###Node#YAML##QBE?BVBinary#1#XZ) parsertests.obj
Error 2 fatal error LNK1120: 1 unresolved externals ....\yaml-cpp_dll\build\test\Debug\run-tests.exe 1
using the general steps mentioned by the user at http://code.google.com/p/yaml-cpp/issues/detail?id=88
cd yaml-cpp for 'yaml-cpp-0.3.0'
mkdir build
cd build
cmake -DBUILD_SHARED_LIBS=ON -G "Visual Studio 8 2005" ..
Looking for help how to fix this. Any inputs is appreciated.
I had the same linking error with Visual Studio 9 2008. The problem is that the >> operator declared in binary.h is not exported. After having done the following modifications in binary.h everything worked fine:
#include "yaml-cpp/dll.h" // add a new include to have YAML_CPP_API defined
...
// add the missing YAML_CPP_API
YAML_CPP_API void operator >> (const Node& node, Binary& binary);
Following on from my previous question regarding debugging of native code, I decided to create a simple test from a console app as I wasn't getting anywhere with debugging the service directly.
So I created a vc6 console app, added the dll project to the workspace and ran it.
Instead of executing as expected it spat out the following linker errors:
main.obj : error LNK2001: unresolved external symbol "int __stdcall hmDocumentLAdd(char *,char *,long,char *,char *,long,long,long,long *)" (?hmDocumentLAdd##YGHPAD0J00JJJPAJ#Z)
main.obj : error LNK2001: unresolved external symbol "int __stdcall hmGetDocBasePath(char *,long)" (?hmGetDocBasePath##YGHPADJ#Z)
Debug/HazManTest.exe : fatal error LNK1120: 2 unresolved externals
This seems to be a simple case of forgetting something in the linker options: However everything seems to be normal, and the lib file, dll and source is available. If I change the lib file to load to nonsense it kicks up the fatal error LNK1104: cannot open file "asdf.lib", so that isn't a problem.
I have previously linked to dll and they have just worked, so what I have forgotton to do?
Update: As per this thread I looked to see if I could find out any additional information. This is what dumpbin from VS2005 gives me.
> dumpbin /linkermember Hazardman.lib | findstr "DocumentLAdd"
F6DC __imp__hmDocumentLAdd#36
F6DC _hmDocumentLAdd#36
5B __imp__hmDocumentLAdd#36
5B _hmDocumentLAdd#36
Then running it through undname results in:
> undname ?_hmDocumentLAdd#36
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.
Undecoration of :- "?_hmDocumentLAdd#36"
is :- "?_hmDocumentLAdd#36"
Which is wrong. If I put in the mangled name from the IDE it gives the lot better result of:
> undname ?hmDocumentLAdd##YGHPAD0J00JJJPAJ#Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.
Undecoration of :- "?hmDocumentLAdd##YGHPAD0J00JJJPAJ#Z"
is :- "int __stdcall hmDocumentLAdd(char *,char *,long,char *,char *,long,long,l
ong,long *)"
Now I have this information, what can I do with it? It seems from this Raymond Chen article I can manually fix it but tweaking an option, but my I can't discern from my results what option is needed (is there an 'ignore all parameters' checkbox?!).
So it seems that it is looking for non-existant functions or the parameters of the function have been left off (or dumpbin doesn't like VC6 libs), but it stil doesn't get me nearer my goal of fixing my problem.
Are you using the correct calling convention?
Your library appears to use stdcall. Maybe your test code is using cdecl (appears to be the default).
According to this page, the linker name decorations differ between the caling conventions so this can explain the symptoms you are seeing.