When building my application in Debug mode: The build works. The application works.
When building my application in Release mode, I get the following error message
error LNK2019: unresolved external symbol __imp__GetClassNameA#12 referenced in function _eachWindow#8
All implementation files of my application have a .c extension; that however doesn't mean I would know which compiler is used by visual studio.
From the documentation of GetClassNameA I can see that a library User32.lib is required. I have found a library with that name in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib>
I have added that directory to the property pages:
Configuration Properties > Linker > General > Additional Library
Directories
but that did not help. I am still receiving that error message.
Thanks for help. I know this question has been asked before, but the previous answers did not help me.
Please help in baby steps, I am still overwhelmed by Windows programming.
Does _eachWindow call GetClassName? Then you need to link user32.lib. Check the additional dependencies in the project's linker settings, not the additional library directories.
– dxiv
dxiv's comment … makes the application work. – chris j
Related
I've built a statically linked library from a project which I downloaded from here InfinityHook project
I'm getting the following two (2) errors in Visual Studio 2017 when I reference any of the functions which are available for export.
Error LNK2019 unresolved external symbol IfhInitialize referenced
in function
DriverEntry HelloWorld_Driver C:\Users\MYSELF\Documents\Visual Studio
2017\Projects\HelloWorld_Driver\HelloWorld_Driver\Driver.obj
Error LNK1120 1 unresolved externals
HelloWorld_Driver C:\Users\MYSELF\Documents\Visual Studio
2017\Projects\HelloWorld_Driver\x64\Debug\HelloWorld_Driver.sys
I get the same type of error when I reference another function from the same infinityhook.h header file and which is statically built in the libinfinityhook.lib file. So basically none of the functions that are "exported" are available to be called and are giving linking errors when referenced from the main project. Before arriving at this conclusion I tried several possible solutions found on StackOverflow but none of them have worked. I've added the statically linked file libinfiinityhook.lib in Visual Studio 2017 Configuration Properties->Linker->Input->Additional Dependencies and the file is located in the correct directory on disk so the linker can find it. But I also added the directory path to this library file to the following settings in VS2017 Configuration Properties->Linker->General->Additional Library Directories.
If anyone else is having the same issue the problem was that I was calling the two C++ defined functions, declared as C++ functions from a "C" based module. Recompiled the static library with the keyword extern and all is working as it should.
I am not familiar with C/C++ but I have to use vsvars32.bat to build an executable file. When I run vsvars32.bat i get some unresolved external symbol errors. I did a little bit of research and it seems that they occur because the lib that contains the definition are not included (Unresolved external symbol in object files).
Here is a one of the error:
libxml2.lib(error.obj) : error LNK2001: unresolved external symbol ___iob_func
I was provided the libxml2.lib file. I'm guessing that I'm getting this error because I need to copy it someplace where vsvars32.bat will look for it. I've been looking through the vsvars32.bat file and it looks like there's three libraries that are defined:
Windows SDK (%WindowsSdkDir%)
NETFXSDK (%NETFXSDKDir%)
UCRTVersion (%UCRTVersion%)
I was able to locate the NETFXSDK library folders on my machine but not the two others. I also noticed that I don't have any system variables named WindowsSdkDir, NETFXSDKDir or UCRTVersion. Is there something else that I should install or run? Am I on the totally wrong track?
During the development of a small project using statically linked OpenSSL 1.0.2e I encountered a strange error in VS13:
Error LNK2001: unresolved external symbol _BN_is_zero
Quite often, this happens when you forget to properly liked .lib file in the project properties, but all of the properties were double-checked - they are correct.
Configuration - Release, MT, libs are MT, bh.h included.
And even if one of the libraries is not linked properly, I should have multiple compiler errors complaining about unresolved external symbols of all the elements used in the project, but in my case unresolved external symbol is the only BN_is_zero.
After quick googling there wasn't found any issues, related to openssl bugs and I guess that the problem resides at my project.
Any tips will be appreciated.
UPD
Here is some screens:
I actually forked the csrp github project and compiled it against the particular openssl libraries you are pointing at. I had to slightly modify test_srp.c and src.c to add some code that isn't available on VS2013. A fork of csrp with the changes applied and the visual studio project for VS2013 to compile it can be found here:
https://github.com/sigmoidal/csrp
Note that you need to change the paths of the openssl path on BOTH the debug and release versions to reflect your VS Configuration Properties:
C/C++ > General > Additional Include Directories
D:\dev\openssl\openssl-1.0.2e-vs2013\include
(you should not point it to $openssl_path/include/openssl, it will not work)
and also:
Linker > Input > Additional Dependencies:
For release configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MT.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MT.lib
For debug configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MTd.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MTd.lib
(notice the "d" suffix on debug libs)
Compiled ok for me.
I'm guessing here, but according to the OpenSSL source BN_is_zero is defined as a macro:
http://osxr.org/openssl/source/crypto/bn/bn.h#0407
So perhaps the module that is compiled into srp.obj is making a call to BN_is_zero but is not including bn/bn.h and in the absence of a prototype the compiler is generating a default one.
If this is the case, including the bn.h definitions should avoid the linker error.
It was tricky, but I've finally solved it based on the Drew MacInnis tips.
The matter is that openssl 1.0.2e broke the BN_is_zero functionality by simply removing the macros-containing header from sources. So, the solution is:
Download the bn.h include file from 1.0.1h (or here)
Place bn.h to %OPENSSL_HOME%/crypto/bn directory
Change #include <openssl/bn.h> for #include <../crypto/bn/bn.h>
I am trying to compile the Win32 Example of the Parrot ARDrone SDK v1.8 using Visual Studio 2012 Express for Windows Desktop. I am running Windows 7 64-bit. The SDK is written in C, not C++.
I've managed to get through every error so far, but this one has me stumped.
When Run, I get these 3 messages in the Error List:
Warning 1 warning LNK4001: no object files specified; libraries used C:\Users\Netex\Desktop\ARDrone_SDK_Version_1_8_20110726\ARDrone_SDK_Version_1_8_20110726\Examples\Win32\VCProjects\ARDrone\Win32Client\LINK Win32Client
Error 2 error LNK2001: unresolved external symbol _mainCRTStartup C:\Users\Netex\Desktop\ARDrone_SDK_Version_1_8_20110726\ARDrone_SDK_Version_1_8_20110726\Examples\Win32\VCProjects\ARDrone\Win32Client\LINK Win32Client
Error 3 error LNK1120: 1 unresolved externals C:\Users\Netex\Desktop\ARDrone_SDK_Version_1_8_20110726\ARDrone_SDK_Version_1_8_20110726\Examples\Win32\VCProjects\ARDrone\Debug\Win32Client.exe Win32Client
I've tried many suggested solutions, including setting the SubSystem in Linker->System to "Not Set" and setting the entry point manually, which gets rid of the 2 errors and replaces it with:
`Error 2 error LNK1221: a subsystem can't be inferred and must be defined'
I've tried setting the Platform Toolset to v90 (which it was originally compiled in, I believe), which gets rid of the warning, but the errors persist.
QUESTION: What is causing these messages, and how can I fix it? Is it because I am trying to compile a Win32 console program on a 64-bit system?
Any help is much appreciated,
Dan
I'm using Qt VS Tools extension with Visual Studio 2019 and working in C++ on a Qt Gui Application created using the new project wizard. In my project properties under Configuration Properties | Linker | System, I have set SubSystem to "Console (/SUBSYSTEM:CONSOLE)" to cause a console window to come up alongside my GUI when debugging. This allows me to view outputs that I've added using qDebug like this:
qDebug() << "Testing";
What I have found is that if I perform a Build | Clean Solution and then Build | Build Solution, I get this error on the first build:
LNK2001 unresolved external symbol mainCRTStartup
Initially I was trying to figure out how to fix this (and ran across this post), but then I found that if I repeated Build | Build Solution the error goes away on subsequent builds, so my solution is to remember to build twice after a clean.
To see what would happen if I had never changed SubSystem to "Console (/SUBSYSTEM:CONSOLE)", I created a new Qt Gui Application project using the wizard. In this project SubSystem is set to "Windows (/SUBSYSTEM:WINDOWS)" as the default. Again I get the error on first build after a clean, but in this case it is a different unresolved symbol:
LNK2001 unresolved external symbol WinMainCRTStartup
Although I'm curious about the cause of the problem, the build twice solution is working for me for now.
in my case, the solution was to explicitly name the 'entry point', e.g. with the command line:
ml64 main.asm /subsystem:console /entry:main
the last option: '/entry:main' was crucial
A windows application I've been working on, is due to delivred without the use of CRT.
There's a few good articles descirbing the guidlines and benefits of doing so (none of which I could find upon writing this question - sorry) . Other then not using CRT symbols explicitly, it's all about linker and compailer configuration. My Release and Debug configurations are nearly identical now , and both specify /NODEFAULTLIB:"LIBCMT" only diffrence is the Run time flag /MT (in Release) vs. /MTd (in Debug) - that is required as I'm using __try/__except syntax for SEH, and so the only needed function is _except_handler3(). However, the Debug version is beeing built successfully, and the Release version fail with Unresolved Symbol _except_handler3 linkage error. When forcing Release version to compile with /MTd - this issue is solved.
How is that possible? which .lib contains the _except_handler3 export? and how can I solve this?
For an application without CRT see: http://blog.kalmbach-software.de/2008/02/02/smallest-application-size-for-win32-console-application/
But if you want to use __try / __except you need to use the CRT; or you need to write your own "_except_handler3".
See also: _except_handler3
Also you have the CRT source, and you can take a look into the source, to see what it is doing!
See: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src