I'm trying to compile the sysvad audio driver example found here: https://github.com/Microsoft/Windows-driver-samples/tree/master/audio/sysvad
Getting a linker error when compiling windows kernel mode driver x64
error LNK2019: unresolved external symbol __stdio_common_vswprintf referenced in function _vsnwprintf_l
Apparently my VC paths are jacked up, but i have tried many things, and cannot find where this lives. I have tried adding libucrt.lib but that gives me a different error:
warning LNK4257: object file was not compiled for kernel mode; the image might not run
Everything compiles fine for Win32 version.
Related
I am building a Windows application based on Qt using VisualStudio 2017 Professional (15.9.35) and the Qt VS Tools add-on. The project compiled fine up to a certain point, now the linker gives the error:
10>MSVCRTD.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol _WinMain#16 referenced in function "int __cdecl invoke_main(void)" (?invoke_main##YAHXZ)
The target Qt version is Qt-5.12.10-msvc2017-32 (my application is 32-bit). My application defines main(), I expect WinMain to be defined by Qt which in turn will call my main() (as stated here, it worked at earlier stages of the development)
What I've checked (in the project for the application, and also in the dependency libraries project that are in the same VS solution):
Qt modules: core;gui;testlib;widgets
Subsystem: Windows (/SUBSYSTEM:WINDOWS)
Character Set: blank (it's not either "Not set", it's set that way by the Qt VS Tools add-on when first creating a project)
Treat wchar_t as built-in type: Yes (/Zc:wchar_t)
I am trying to build tensorflow for win32 with cmake. All is fine until it hit this line:
libprotobuf.lib(descriptor.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' [A:\src\tensorflow\tensorflow\contrib\cmake\build32\proto_text.vcxproj]
Upon checking, the libprotobuf.lib is indeed built as a x64 binary.
So where should I change to make it build a win32 library?
I had the similar linking error when building 32bit tensorflow.dll.
I fixed the problem by manually changing the mangled name of ~OpDef from
??1OpDef#tensorflow##UEAA#XZ
to
??1OpDef#tensorflow##UAE#XZ
(latter I found by running "dumpbin /symbol" on op_def.pb.obj)
this problem is resolved. Apparently during building, tensorflow downloads protobuf, and the generated project file has target machine set to x64. So this was an easy fix.
Now I have encountered a new problem: during building of the pywrap_tensorflow_internal project, the following link error happened:
error LNK2001: unresolved external symbol "public: virtual __cdecl tensorflow::OpDef::~OpDef(void)"
It looks the project is using __cdecl calling convention while the ~OpDef destructor is using __thiscall. And I can't change the calling convention of a class destructor. I have no idea how this could happen.
Any idea on how to fix this calling convention mismatch issue?
After compiling clang and llvm following the instruction on the llvm website I try linking to the built static libs in a test app. All code is built with v110 of the VS toolset. Im getting linker errors of type "error LNK2001" and "error LNK2019".
The app appears to put the libs in the bucket for symbol resolution. With verbose linker output i can see that they are just being dismissed:
1> Unused libraries:
...
1> C:\Sdk\llvm\Debug\lib\clangTooling.lib
...
Digging a little deeper i have found that the symbols in the error message and the ones in the libs are not quite the same.
-Here is an example-
Linker error =>
*unresolved external symbol "public: int __cdecl clang::tooling::ClangTool::run(class clang::tooling::ToolAction )" (?run#ClangTool#tooling#clang##QEAAHPEAVToolAction#23##Z) referenced in function main
...giving "?run#ClangTool#tooling#clang##QEAAHPEAVToolAction#23##Z" as the symbol name.
Now using "dumpbin /SYMBOLS" on my built version of the clangTooling.lib =>
*FDA 00000000 UNDEF notype () External | ?run#ClangTool#tooling#clang##QAEHPAVToolAction#23##Z (public: int __thiscall clang::tooling::ClangTool::run(class clang::tooling::ToolAction ))
... i can see the the symbol im looking for is called
"?run#ClangTool#tooling#clang##QAEHPAVToolAction#23##Z"
There is a very subtle difference near the beginning of the address. Here they are again side by side for comparison.
?run#ClangTool#tooling#clang##QEAAHPEAVToolAction#23##Z << Error Message
?run#ClangTool#tooling#clang##QAEHPAVToolAction#23##Z << Dumpbin Output
Why is it that these do not match?
Thanks
So it turns out the LLVM/clang libraries I had built were 32 bit while my test project was building 64 bit. I have successful built a test project using 32 bit binaries. The notes on this answer Unresolved Externals in C++: Visual C++ mangles method signature differently from mangled method in dll describe the issue in more detail.
*Note for anyone else looking into linking with LLVM libs. The CMake documentation for LLVM/clang (found here http://llvm.org/docs/CMake.html) makes it sound like it defaults to 64 bit on a 64 bit system. On Windows7 64bit/VisualStudio11 (at least on my machine) this isnt the case. I haven't yet found an option to support 64 bit compilation from the CMake menu. For now it seems the only option is to embed into 32 bit apps.
I am trying to built a .cpp file using OpenNI in Visual Studio 2012. I am using the code of the SimpleViewer sample (it is included in the OpenNI). When I try to build the .cpp file I got the error LNK2019 which it seems a problem when the compiler has to link the OpenNI library. What could be wrong?
Errors (55 in total):
> Error 1 error LNK2019: unresolved external symbol __imp__oniShutdown
> referenced in function "public: static void __cdecl
> openni::OpenNI::shutdown(void)"
> (?shutdown#OpenNI#openni##SAXXZ) C:\Develop\VisualStudioWorkspace\Projects\My
> programs\OpenNI2_test\OpenNI2_test\Viewer.obj OpenNI2_test
Error 2 error LNK2019: unresolved external symbol __imp__oniWaitForAnyStream referenced in function "public: static enum openni::Status __cdecl openni::OpenNI::waitForAnyStream(class openni::VideoStream * *,int,int *,int)" (?waitForAnyStream#OpenNI#openni##SA?AW4Status#2#PAPAVVideoStream#2#HPAHH#Z) C:\Develop\VisualStudioWorkspace\Projects\My programs\OpenNI2_test\OpenNI2_test\Viewer.obj OpenNI2_test
I followed all the steps described in the OpenNI website to compile a file in Visual Studio: I added all the VCC Directories and the Include and Lib environment variables. I also added OpenNI2.lib in the additional dependencies on the Linker section. I also copied the Redist files in the working directory (the directory where I have the .vcproj).
I ran into a similar issue. The sample projects wouldn't build because I was using OpenNI for x64 but the platform was set to Win32. Changing to x64 (in the properties dialog at the top) fixed it for me.
OpenNI 2.0 is not mature enough. Most of the libraries, open source codes, examples and wrappers still use OpenNI 1.5. The integration is not easy since OpenNI2 uses the Microsoft official drivers and OpenNI1.x uses the open source drivers. The 32bit version gives less problems than the 64bits but I ended up installing and working the OpenNI 1.5 and the Kinect non-official drivers.
The problem is related to the linking process. You may have wrong link path in the properties of your projects. There is solution, check this question
maybe it works in your case!
I'm using CMake to build a Qt based application of mine on Windows with Visual Studio 2010 Express. When configuring with cmake I get the following error:
System runtime library file does not exists:
'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcp100.dll
System runtime library file does not exists:
'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcr100.dll
Then when I try to compile, I'm getting this error (both trying in Visual Studio, and with msbuild):
MSVCRT.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain#16 referenced in function ___tmainCRTStartup
C:\Users\Kurtis\sandbox\UDJ-Desktop-Client\build\src\Release\UDJ.exe : fatal error LNK1120: 1 unresolved externals
I determined that Microsoft Visual C++ 2010 Express doesn't come with the redistributable that I need. So I went to Microsoft's website to download the redistributable (both for x86 and x64). However, after installing it, I'm still getting the above configure and compile errors. Does anyone know what I'm doing wrong, or how to fix my problem?
_WinMain#16 is the entry point of a Windows GUI application, so either it's missing from your source code, or you're not writing a GUI application, in which case your linker flags are incorrect.
Since you're using qt, make sure you have the QtMain Library being linked with your project. You can do this by adding it in your call to Find_Package like so:
find_package(Qt4 4.7.0 COMPONENTS QtMain QtCore QtGui QtSQL Phonon REQUIRED)