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.
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 am trying to set up a project in visual studios for C but every time i do, i first get this error message
fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?
then when i fix it by going into the "Properties->Precompiled header" i get this message
error LNK2005: _main already defined in clang.obj
. This has been going on for days now and i watched a bunch of videos and read a bunch of articles on this and I can't seem to find a fix. I just want to run my C program and have it execute without dealing with errors like those above. Here is what i do to set it up,
Create new project -> Select "Windows console application" -> change the "Location" to a file directory on my desktop -> then go to "Project" and "Add new item" -> i name that item "name.c" and when I am done, I insert my code and run it then i receive the same errors. Can someone please help me.
I think the problem is that when you choose Windows console application template, VS 2017 already generated a file which has a int main() function defined in it.
Then you added another file name.c which also has a main() function. Thus you got that error.
Hello industry veterans,
I am a junior in college embarking on my first summer programming internship, and I am in way over my head. The company I'm working for has purchased a colossal application from another company that has slowly been expanding and modifying it since the early 90's. The solution contains over 200,000 lines of code which are spread across more than 300 files. The entire solution has purportedly been written to ANSI-C++ standards. The code is almost entirely undocumented, and most of it looks like hieroglyphs to me. Ultimately, my job is to port this code to embedded Linux. At the moment, my job is simply to get it compiling using Visual Studio 2008 on Windows XP.
Today, I'm running into linker errors such as this one:
libcmtd.lib(sprintf.obj) : error LNK2005: _sprintf already defined in msvcrtd.lib(MSVCR90D.dll)
My understanding is that this often happens when different projects within a solution are compiled using different runtime libraries. There are 6 projects in my solution. 4 of them were set to compile using the multi-threaded debug DLL runtime library (/MDd), one of them was set to compile using the multi-threaded debug library (/MTd), and one of them was set to compile using the multi-threaded dll runtime library (/MD). The first thing I tried after receiving this error message was to change the /MTd and /MD switches to /MDd so that everything would have compiled with the same runtime libraries. Unfortunately, this led to the following error in afx.h:
fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
After some digging around, I discovered that it had already told me what I needed to do. I went ahead and changed the "Use of MFC" option under Project Properties->Configuration Properties->General to "Use MFC in a Shared DLL". At this point I started receiving dozens of unresolved external errors such as these:
dataPropertySheet.obj : error LNK2019: unresolved external symbol "public: __thiscall CResizableSheet::CResizableSheet(unsigned short const *,class CWnd *,unsigned int)" (??0CResizableSheet##QAE#PBGPAVCWnd##I#Z) referenced in function "public: __thiscall CdataPropertySheet::CdataPropertySheet(unsigned short const *,class CWnd *,unsigned int)" (??0CdataPropertySheet##QAE#PBGPAVCWnd##I#Z)
ResizableLib.lib(ResizablePage.obj) : error LNK2001: unresolved external symbol "public: virtual int __thiscall CWnd::Create(char const *,char const *,unsigned long,struct tagRECT const &,class CWnd *,unsigned int,struct CCreateContext *)" (?Create#CWnd##UAEHPBD0KABUtagRECT##PAV1#IPAUCCreateContext###Z)
After reading through the MSDN pages on LNK2001 and LNK2019, I've realized I have no idea what's going on. These are not the sort of issues they've taught us how to deal with in school. I know my data structures, and that's about it. How I ended up where I am now is beyond me!
From my limited knowledge, it seems that the various debug and release versions of these modules are all tangled up in a web of preprocessor directives and #includes. There are a number of nested #ifdef checks and #define statements done in nearly every header and source file throughout the solution for environment variables, file names, macros, and possibly more. By making even small changes to my compiler settings, I seem to be redirecting large parts of the program to different libraries which have very different function definitions. This is my vague conceptual understanding of what's going on.
I feel as though I'm going to need a better understanding of how this code works before I stand any chance of troubleshooting these compiler errors. To that end, I've been trying to step through many of the files line by line to see where they lead, what objects and variables are in scope, and so on. Unfortunately, this doesn't get me very far, because every call to an external function is ambiguous, and I have no way of seeing through the preprocessor mess to know which version of any given function is supposed to be called.
I was looking around for magic solutions to map out the program and try to make sense of it. I tried one called Doxygen, but either I don't know how to use it properly or it's getting just as confused by the preprocessor stuff as I am.
My question is this:
What are my remaining options?
At this point it's a toss up between:
a.) Switch majors
b.) Jump off a bridge
Neither of these choices are going to help me better understand this code base and get it compiling. Does anybody have any better ideas? Similar experiences? Sage wisdom to share?
Thanks a ton,
-Alex
It appears you're using the CResizableSheet and CResizeablePage from CodeProject. If you're using the compiled static lib from that page, you could try downloading the source and compiling that with the matching /MDd setting and using the .lib it outputs in the linker input section of your project. I'd also suggest doing a clean all (go to build->batch build->select all then click clean) and then try building again to make sure everything is up to date.
I hear nursing is a great program ...
At the risk of being pedantic, what you are fighting with are linker errors, not compiler errors. My basic approach to this would be to create a new solution, and start adding projects one at a time, getting each one to build in turn.
I would also seriously consider trying to standardize the settings of each project as much as possible. The easiest way to do this is to create empty projects in your new solution, and copy the existing code into them.
To start with you should assume the following settings (related to MFC):
Debug: Use MFC in a shared DLL, /MDd
Release: Use MFC in a shared DLL, /MD
MDd and MD are the same mode, but one links against debug libraries with extra information for debugging.
Then all you can do is work on one project at a time. Note that if you create a new solution as suggested, you'll need to rebuild the dependency tree between projects. (Right click on a project and choose 'Dependencies', you'll see what I mean.)
When you run into problems doing this, you should make friends with a senior developer at your workplace =).
Compile everything with the same runtime libraries. End of story.
I've been using CodeBlocks for a while now as I make a little hobby game in C++. Come across a snag whereby I want to see the current values of all the data in my arrays at any point, CodeBlocks doesn't seem to have that ability. Have been told by workmates (professional game programmers) that I should use Visual Studio.
Have previously used Visual Studio C# in the past, was very handy being able to use a break point while debugging other small games I've made and then going through the big list of watches to look at particular array values or any other value from within my program at that time.
So I've created a new blank project in VC2010 and added all my code files to the project. I know I have to link libraries and such, have spent the last few hours trying to figure out how to do that. But even after all that is done, I'm still getting link errors (I think)
First problem is this:
fatal error C1083: Cannot open include file: 'gl\glext.h': No such file or directory
So I commented it out to see how much further I could get.
Eventually had to add to my main.cpp file
#pragma comment (lib, "opengl32.lib")
#pragma comment (lib, "glu32.lib")
#pragma comment (lib, "libsoil.lib")
I ended up copying the libsoil.a file to C:\Program Files\Microsoft Visual Studio 10.0\VC\lib and renaming it to libsoil.lib (as stated on the authors's website http://www.lonesock.net/soil.html)
So now I get this when I compile
1>libsoil.lib(stb_image_aug.o) : error LNK2019: unresolved external symbol ___chkstk referenced in function _stbi_zlib_decode_noheader_buffer
1>libsoil.lib(image_helper.o) : error LNK2019: unresolved external symbol _sqrtf referenced in function _RGBE_to_RGBdivA2
1>C:\Repositories\HappyHelperPuppy\CppVer\HappyHelperPuppy\Debug\HappyHelperPuppy.exe : fatal error LNK1120: 2 unresolved externals
..And I have no idea what to do next. I've spent ages in Google and trawling through forums and I really just don't know what to do.
So as a last ditch effort I'm zipping up all my code and project files and letting anyone whos interested to have a look and see if they can find a solution. It's not like this game will have any secret feature I want to keep under wraps, and all the art is from an open game competition from ages ago ("TIGSource Assembly" for those who know what it is) or from DeviantArt (just wanted something to look at while I made it, wouldn't be final game release art)
The code/game can be found here http://users.on.net/~infernoraven/hhp_busted_code.zip (27mb)
The SOIL library should be in the main directory in its own soil.zip
Any help would be good, but I'm just getting really depressed as I seem to spend most of my time either fighting with the IDE/Compilers or some annoying syntax problem.
The CodeBlocks project files should be in there also, so if you..
un-comment out glext.h
link to SOIL
link to libopengl32 and libglu32
Hopefully it'll compile for you. Otherwise there should be an HappyHelperPuppy.exe that's precompiled by CodeBlocks that should hopefully run and give you an idea of what is suppose to happen
In the SOIL package there are a number of project files for visual studio. When I try to load up the VC9 one and convert it to VC10, I get conversion errors.
Conversion Report - SOIL.vcproj:
Converting project file 'C:\Documents and Settings\Administrator\My Documents\Downloads\soil\Simple OpenGL Image Library\projects\VC9\SOIL.vcproj'.
Failed to upgrade platform 'x64'. Please make sure you have it installed under '%vctargetspath%\platforms\x64'
VCWebServiceProxyGeneratorTool is no longer supported. The tool has been removed from your project settings.
Attribute 'Detect64BitPortabilityProblems' of 'VCCLCompilerTool' is not supported in this version and has been removed during conversion.
Attribute 'Detect64BitPortabilityProblems' of 'VCCLCompilerTool' is not supported in this version and has been removed during conversion.
Failed to upgrade 'Debug|x64'. Please make sure you have the corresponding platform installed under '%vctargetspath%\platforms\x64'
The project configuration dimension name/value "(Platform, Win32)" was not found in the project manifest.
Project upgrade failed.
If I use the VC8 project file and try to upgrade that, a libSOIL.lib file is generated by VC2010 throws an error saying "Unable to start program ... \SOIL.lib The specified file is an unrecognized or unsupported binary format"
But the author on his site states that I can simply rename the libSOIL.a file to a libSOIL.lib file and it should work.
The soil.zip file contains some .sln files under the folder projects. Use the proper .sln file to build the library, then link your project against this library. It worked fine on my side.
Trying to use arguments for external tools within the custom build option in VS2010 but they seem to be empty, specifically:
c:\oracle\ora10g1\bin\proc $(ProjDir)\$(ItemFilename).pc
Fails with:
PCC-F-02101, Unable to open input file: ".pc"
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
Yet file exists and hardcoded reference compiles.
Try enclosing the macros in double-quotes...
c:\oracle\ora10g1\bin\proc "$(ProjDir)\$(ItemFilename).pc"
I suspect your problem is the embeded spaces in the final path.
OK - I figured it out - there is a "macro" button in the dialog for specifying the custom build arguments - it has the correct definitions.
here's what works:
c:\oracle\ora10g1\bin\proc $(ProjectDir)%(Filename)%(Extension)
I believe that the doco that referenced "Arguments for External Tools" is either incorrect or they don't consider args used within the custom build dialog to be feeding an external tool.