Under Visual C++, I have played around with Glut/FreeGlut/GLFW. It seems that everyone of these projects adds a CMD window by default. I tried removing it going under:
Properties->C/C++->Preprocessor->Preprocessor
Definitions
From here, I remove the _CONSOLE and replace it with _WINDOWS
Then I went under:
Properties->Linker->System->SubSystem
And I set the option to Windows (/SUBSYSTEM:WINDOWS)
Then when I try compiling under GLFW, I get the following building errors:
Error 1 error LNK2001: unresolved
external symbol _WinMain#16
MSVCRT.lib
Error 2 fatal error LNK1120: 1
unresolved externals glfwWindow.exe
Is it possible to remove the console window?
Under the linker options, set your entry point to mainCRTStartup . This function does the necessary setup of the MS libc and then calls main.
Most linkers support options that automatically remove the console startup code.
I think on GCC it's called -mwindows
My project just has a main, (no WinMain) and to disable console, I just set Linker->System->SubSystem to "Windows (/SUBSYSTEM:WINDOWS)" instead of "Console (/SUBSYSTEM:CONSOLE)" and the console goes away.
You don't need to mess with the Preprocessor Definitions to remove the console window.
I know my answer is a few years late, but I hope it helps.
To get rid of the console using cmake, the link flags can be set as follows:
set_target_properties(exe_name PROPERTIES
LINK_FLAGS "/ENTRY:mainCRTStartup /SUBSYSTEM:WINDOWS")
Non-console Windows applications use the WinMain() entry point convention. Your Glut examples probably use the standard C main() convention.
If you want a quick fix just for the demo app, the WinAPI function FreeConsole() might help.
MSDN: http://msdn.microsoft.com/en-us/library/ms683150(v=vs.85).aspx
You need to write a WinMain entry point and copy your existing code (from main):
int CALLBACK WinMain(
__in HINSTANCE hInstance,
__in HINSTANCE hPrevInstance,
__in LPSTR lpCmdLine,
__in int nCmdShow
){
// ...
}
If you create a new project as a console application, it will always run as such. You have to create a new GUI project if you want to run it in an actual window, otherwise the correct headers and libraries will not be included.
Also the WinMain function that's required will be included for you in the resulting template files.
When I've gotten an error like that I was able to fix it by entering that following text in the linker, section Advance, option Entry Point the following:
main
Related
A third party library in my program is trying to call __scrt_common_main_seh by way of the Microsoft library msvcrt.lib, but is defined by some unknown library and therefore gives a linker error. I don't know what this function is supposed to do or where it is defined.
I looked online for this function, but did not find any clues except for general descriptions of what linker errors are.
I believe it might be doing some setup for win32 GUI applications. The library which defines it might be configured as project dependency by Visual Studio but my project is using Bazel.
Summary
For non-console applications having error error LNK2019: unresolved external symbol main referenced in function "int __cdecl __scrt_common_main_seh(void)" try adding linker flag /ENTRY:wWinMainCRTStartup or /ENTRY:WinMainCRTStartup
For console applications having that error, make sure to implement a main() function.
Details
This answer shows that __scrt_common_main_seh is normally called during mainCRTStartup which is the default entry point for windows console applications. __scrt_common_main_seh is then (indirectly) responsible for calling main().
My program did not have a main() function, which might have prevented the compiler from generating __scrt_common_main_seh (Just speculating. I am totally clueless about who defines __scrt_common_main_seh)
I did find, however, that the library I was linking against defined a wWinMain() function. So I tried adding the linker flag /ENTRY:wWinMainCRTStartup and the linker error went away.
I have code written in C++ on windows.
My code compiles and links when I compile it as x64 but not when I change the build configuration to x86.
The failure is a linking error.
I'm using the function RtlIsNameInExpression from ntdll.
When I compile it in 32bit mode I get a linkage error (LNK2019) of unresolved external.
Any ideas why this might happen?
10x
first of all - how you declare function and which symbol can not found linker ?
declaration must be
extern "C" NTSYSAPI BOOLEAN NTAPI RtlIsNameInExpression(
_In_ PCUNICODE_STRING Expression,
_In_ PCUNICODE_STRING Name,
_In_ BOOLEAN IgnoreCase,
_In_opt_ PWCH UpcaseTable
);
i can guess that you miss NTAPI i.e __stdacall keyword if you copy-paste from here. for x64 exist only one calling convention, but for x86 exist different between __stdcall and __cdecl for example. this can explain why this found in x64 but not found in x86
what error give you linker (not compiler !) ? unresolved external symbol __imp__RtlIsNameInExpression ? (if yes you really forget __stdcall set) or __imp__RtlIsNameInExpression#16 ? in this case you declare function correct, but your ntdll.lib not containing this symbol. (may be you use old ntdll.lib
for xp ? ) simply search __imp__RtlIsNameInExpression#16 string as is in ntdll[p].lib - are it found ? if not you have old (xp) version of ntdll i guess.
The answer is in the online documentation for that function:
This function has no associated header file. The associated import library, Ntdll.lib, is available in the Microsoft Windows Driver Kit (WDK). You can also call this function using the LoadLibrary and GetProcAddress functions to dynamically link to Ntdll.dll.
If you can't add the ntdll.lib file from the WDK to your link command, then you need to use the LoadLibrary-GetProcAddress approach.
Also from the same section of documentation:
The functions and structures in Winternl.h are internal to the operating system and subject to change from one release of Windows to the next, and possibly even between service packs for each release. To maintain the compatibility of your application, you should use the equivalent public functions instead. Further information is available in the header file, Winternl.h, and the documentation for each function.
This question already has answers here:
How do I create a C++/CLI Winforms app in VS2012?
(2 answers)
Closed 8 years ago.
Okay so I am just beginning to learn C++ and I would like to do so using Windows Forms. I created a Blank project and tried to add a form. I get this error.
Error 2 error LNK1120: 1 unresolved externals C:\Users\Ryan\Google Drive\C++\Hello C++\Debug\Hello C++.exe 1 1 Hello C++
&&
Error 1 error LNK2001: unresolved external symbol _main C:\Users\Ryan\Google Drive\C++\Hello C++\Hello C++\LINK Hello C++
I have set my Startup to main and set SubSystem to Windows (/SUBSYSTEM:WINDOWS)
My Project is called Hello C++ and my form is called MyForm.
Any help?
Cheers
You're adding Windows Forms (which are forms for C# or VB.NET) to a C++ project.
This is not gonna work: C++ is an unmanaged language while you're adding a form for a managed language.
Put it simply: Windows Forms are usable if you choose "C#" or "Visual Basic .NET" as a VS project.
In addition to the "Forms" problem, setting /SUBSYSTEM:WINDOWS means your program is required to have a winmain entry point, not main. That is probably the reason for the error. (You did not show us the complete error message.)
To use Forms change languages to C#. To build a GUI in C++ you can use a Win32 app, or MFC, or ATL, or Qt.
Well the entry point should be
int CALLBACK WinMain(
_In_ HINSTANCE hInstance,
_In_ HINSTANCE hPrevInstance,
_In_ LPSTR lpCmdLine,
_In_ int nCmdShow
);
and not the usual "main". There is good reason for that and you can read about it here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559(v=vs.85).aspx
I am currently facing a problem which is as the error below
Error 1 error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup MSVCRTD.lib assignment
I am trying to redo the program, I have follow the step to do as same as article post by any user. I try to change the character set to not set, still no function available. I try to change from console to win turn out _winmain#16 error, and I change back _main error
I ald recreate the whole solution file i didnt recreate the coding or .CPP and .H file in my C++ programming,
How do I solve it, I already research for 3 - 4 days, but I still unable to get the answer that I have expect. Hopefully this may help me to complete the program. Thank you and your help much appreciated.
You've probably got some incompatible settings in your solution. In Visual Studio 2010, Create a new project, and select Win32 Console Application from the templates list. Click Next on the Wizard page, and select Console Application, and Empty Project, then Finish. Create a new .cpp file and put this code into it
int main ()
{
}
This should compile and link.
if it is an windows program：
1.menu-Project->Properties, to open this "Property Pages" window
2.then choose Configuration Properties->C/C++->Preprocessor,and delete "_CONSOLE" in Preprocessor Definitions , add "_WINDOWS".
3.return the first step:Configuration Properties->Linker->System,change it to Windows(/SUBSYSTEM:WINDOWS) in SubSystem
if it it a console program：
1.menu--> Project->Properties, pop out the "Property Pages" window
2.then choose Configuration Properties->C/C++->Preprocessor,and delete "_WINDOWS" int Preprocessor Definitions add "_CONSOLE".
3.return the first step：Configuration Properties->Linker->System,change it to CONSOLE(/SUBSYSTEM:CONSOLE) in SubSystem
Do you have a main function in your program? Because the windows runtime library (The MSVCRTD.lib you mentioned) will call your main function as the entry point. If you don't have one, there is a link error.
WinMan is the entry point for the win32 program.
I'm working on a fairly convoluted project in which I'm accessing classes written in plain-old-C++ from a project using C++/CLI. It's a Windows Forms GUI project that uses a lot of the same functions as its (non-CLI) C++ sister project.
In one of my classes that I'm trying to adjustment to work in both environments, I'm polling keypresses with this function:
inline bool IsKeyDown(unsigned char ch) const {
return (GetAsyncKeyState(ch) & (1u << 15)) != 0;
}
I'm getting both Unresolved Token and Unresolved External Symbol errors on
"extern "C" short __stdcall GetAsyncKeyState(int)" (?GetAsyncKeyState##$$J14YGFH#Z) referenced in function "public: bool __clrcall Engine::InputManager::IsKeyDown(unsigned char)const " (?IsKeyDown#InputManager#Engine##$$FQBM_NE#Z)
Obviously, the issue is related to GetAsyncKeyState() but I'm not sure what needs to be different for a CLI-friendly implementation. Can anyone direct me how to fix this? The function works properly in my non-CLI environment (and has for months). I'm very new to this CLI stuff so any help would be wonderful and no help could be too-specific.
If it helps, I'm using Visual Studio 2010 and compiling with the /clr parameter (not :pure or :safe).
The MSDN library provides the details of which header files and libraries need to be included for any particular function.
In this case, you need windows.h (which you must already have) and user32.lib (which is probably missing). So add
#pragma comment(lib, "user32.lib")
at the top of your code and all should be well. Alternatively, you could add user32.lib to the list of libraries in the project properties pages, remembering to do this for each configuration, e.g., debug as well as release.
Just got the same issue. The solution is to link against a .lib which has a respective symbol, which in this case is user32.lib.
I fixed a problem in Visual Studio by making a project use inherited values. Check this checkbox in your project properties and it should fix it: