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.
Related
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.
Seems like many people hit this and there seems to be no solution that I can find.
Follow exact instructions, downloaded precompiled libs, v 3.0.5 - latest stable build
set wxwin env var
make new 32bit empty project
copy the hello world app into new source file
set additional include
set preproc defintions -> UNICODE & _UNICODE on
set linker libs
build ->
1>------ Build started: Project: wxtest, Configuration: Debug Win32 ------
1>Source.cpp
1>c:\work\wxwin\include\wx\wxcrt.h(487): error C3861: 'wxStrcoll': identifier not found
1>c:\work\wxwin\include\wx\wxcrt.h(487): message : 'wxStrcoll': function was not declared in the template definition context and can be found only via argument-dependent lookup in the instantiation context
1>c:\work\wxwin\include\wx\wxcrt.h(496): message : see reference to function template instantiation 'int wxStrcoll_String<const wchar_t*>(const wxString &,const T &)' being compiled
1> with
1> [
1> T=const wchar_t *
1> ]
1>Done building project "wxtest.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Unfortunately you need to manually modify the header to fix the build with MSVS 2019 in 3.0.5 and remove defined(__VISUALC__) || part of the check before wxNEEDS_DECL_BEFORE_TEMPLATE definition in wx/wxcrt.h.
FWIW this problem was fixed since a long time (~6 years) in wx 3.1 and you can compile 3.1.3 or the soon to be released 3.1.4 out of the box with MSVS 2019.
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.
This problem seems to be pretty common to anyone dealing with c++/cli, but I'm missing something with the typical resolution path. I have a .Net assembly, PHD.exe, that has a reference to a c++/CLI dll. This DLL dynamically links a number of win32 native dlls.
Exception text:
Main Window Exception: The type initializer for 'X.BLCInterfaceBehavior' threw an exception. System.BadImageFormatException: Could not load file or assembly 'CppCLI.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
Following other recommendations on SO, I check the target type for my executable. Right click > Properties > Build Tab > Platform = x86. Platform Target: x86.
Likewise, I check the project properties for the c++/cli dll ( I hope this is the correct place to look): Properties > Configuration Properties > Linker > Target Machine = MachineX86
I ran DependencyWalker on the CppCLI.dll, and get the following errors:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
I'm not sure how to identify which DLL is missing an expected export function, or if this is just one of this depends.exe quirks on an x64 system. Same thing applies to the modules with diff cpu types - I think I have seen "ignore that" message here on SO.
I ran the app against winDBG, and see that some windows DLLs are loading from SysWOW64 - this seems like its wrong. Some examples:
ModLoad: 75880000 75910000 C:\Windows\syswow64\GDI32.dll
ModLoad: 753f0000 753fa000 C:\Windows\syswow64\LPK.dll
ModLoad: 76c60000 76cfd000 C:\Windows\syswow64\USP10.dll
ModLoad: 76d00000 76da0000 C:\Windows\syswow64\ADVAPI32.dll
ModLoad: 75fe0000 76c2a000 C:\Windows\syswow64\SHELL32.dll
Shouldn't these be loaded from System32?
Finally WinDBG shows the exception, but I don't see anything useful:
ModLoad: 6dfc0000 6e060000 GambitManagedWrapper.dll
ModLoad: 01270000 01310000 GambitManagedWrapper.dll
ModLoad: 72eb0000 72ebe000 C:\Windows\SysWOW64\RpcRtRemote.dll
ModLoad: 6dfc0000 6e060000 C:\Gambit\GambitManagedWrapper.dll
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): CLR exception - code e0434352 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): CLR exception - code e0434352 (first chance)
(fbc.ebc): CLR exception - code e0434352 (first chance)
Additionally, I ran this command in winDBG, which further confuses things for me:
effmach #
Effective machine: x86 compatible (x86)
Not really sure where to go from here, and would appreciate any and all suggestions.
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);