error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

I don't know what's wrong with it.. I can't find where the error is, commenting out the implementation doesn't resolve the error either.

Header File

#ifndef MAIN_SAVITCH_SEQUENCE_H
#define MAIN_SAVITCH_SEQUENCE_H
#include <cstdlib>  // Provides size_t

namespace main_savitch_3
{
    class sequence
    {
    public:
        // TYPEDEFS and MEMBER CONSTANTS
        typedef double value_type;
        typedef std::size_t size_type;
        static const size_type CAPACITY = 30;
        // CONSTRUCTOR
        sequence( );
        // MODIFICATION MEMBER FUNCTIONS
        void start( );
        void advance( );
        void insert(const value_type& entry);
        void attach(const value_type& entry);
        void remove_current( );
        // CONSTANT MEMBER FUNCTIONS
        size_type size( ) const;
        bool is_item( ) const;
        value_type current( ) const;
    private:
        value_type data[CAPACITY];
        size_type used;
        size_type current_index;
    };
}

#endif

Source

#include "sequence1.h"
#include <assert.h>

namespace main_savitch_3
{

	// Default constructer - sequence is empty
	sequence::sequence()
	{
		used = current_index = 0;
	}


	// Start the iteration
	void sequence::start()
	{
		current_index = 0;
	}
	// Iterate
	void sequence::advance()
	{
		current_index++;
	}


	// Number of items in the sequence
	sequence::size_type sequence::size() const
	{
		return used;
	}
	// Checks if there is a current item
	bool sequence::is_item() const
	{
		return current_index <= used && used > 0;
	}
	// Returns the current value
	sequence::value_type sequence::current() const
	{
		assert(is_item()); // no current item
		return data[current_index];
	}


	// Adds an item BEFORE the current index
	void sequence::insert(const value_type& entry)
	{
		assert(entry != 0); // pointer is invalid
		assert(current_index < sequence::CAPACITY); // no room to add an item

		// move items up - starting with the last item and working down to the current item
		// arrays start at 0, so the -1 adjusts it
		for (size_type i = used - 1; i >= current_index; i--)
			data[i + 1] = data[i];
		
		data[current_index] = entry;
	}
	// Adds an item AFTER the current index
	void sequence::attach(const value_type& entry)
	{
		assert(entry != 0); // pointer is invalid
		assert(current_index < sequence::CAPACITY); // no room to add an item

		// move items up - starting with the last item and working down to the current item
		// arrays start at 0, so the -1 adjusts it
		for (size_type i = used - 1; i > current_index; i--)
			data[i + 1] = data[i];

		if (current_index = 0)
			data[used] = entry;
		else
			data[current_index + 1] = entry;
	}
	// Removes the current item
	void sequence::remove_current()
	{
		for (size_type i = current_index; i < used; i++)
			data[i] = data[i + 1];
	}

}

Even if your project has a main() method, the linker sometimes gets confused. You can solve this issue in Visual Studio 2010 by going to

> Project -> Properties -> Configuration Properties -> Linker -> System

and changing SubSystem to Console.

We also had this problem. My colleague found a solution. It turned up to be a redefinition of "main" in a third party library header:

#define main	SDL_main

So the solution was to add:

#undef main

before our main function.

This is clearly a stupidity!

if you have _tmain function in your projects you need to include <tchar.h>.

You need a main() function so the program knows where to start.

In case someone missed the obvious; note that if you build a GUI application and use
"-subsystem:windows" in the link-args, the application entry is WinMain@16. Not main(). Hence you can use this snippet to call your main():

#include <stdlib.h>
#include <windows.h>

#ifdef __GNUC__
#define _stdcall  __attribute__((stdcall))
#endif

int _stdcall
WinMain (struct HINSTANCE__ *hInstance,
         struct HINSTANCE__ *hPrevInstance,
         char               *lpszCmdLine,
         int                 nCmdShow)
{
  return main (__argc, __argv);
}

If you are using Visual Studio. The reason you might be recieving this error may be because you originally created a new header file.h and then renamed it to file.cpp where you placed your main() function.

To fix the issue right click file.cpp -> click Properties go to
Configuration Properties -> General ->Item Type and change its value to C/C++ compiler instead of C/C++ header.

Did you implement the main() function?

int main(int argc, char **argv) {
    ... code ...
    return 0;
}

[edit]

You have your main() in another source file so you've probably forgotten to add it to your project.

To add an existing source file: In Solution Explorer, right-click the Source Files folder, point to Add, and then click Existing Item. Now select the source file containing the main()

I had this problem despite:

• having a main(); and
• configuring all other projects in my solution to be static libraries.

My eventual fix was the following:

• my main() was in a namespace, so was effectively called something::main() ...removing this namespace fixed the problem.

I encountered the LNK2019 error while working on a DLL project in Visual Studio 2013.

I added a new configuration to the project. But instead of having the "Configuration Type" as "Dynamic Library", visual studio added it as "Application". This resulted in the LNK2019 error.

Fixed the LNK2019 error by going to Project -> Properties -> Configuration Properties -> General and changing "Configuration Type" to "Dynamic Library (.dll)" and "Target Extension" to ".dll".

Yes, the original question talks about a console/application project, which is a different problem than my answer. But I believe adding this answer might help someone (like me) that stumbles upon this thread.

You appear to have no main function, which is supposed to be the entry-point for your program.

In visual studio, project properties, for x86, x64, Release and Debug Configurations

Linker > System > SubSystem

For /SUBSYSTEM:WINDOWS The following main is required (Note this is for the unicode, wide character version):

#include <Windows.h>

int WINAPI  wWinMain(_In_ HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPWSTR    lpCmdLine,
    int       nCmdShow)
{
   return 0;
}

For /SUBSYSTEM:CONSOLE The following main is required :

int main(int argc, char* argv[], char* environment[]){
      return 0;
}

My Problem was something else
I had a method in a class with no implementation.
like this:

class Hello {
	public:
		// ...
		void PrintHelloWorld();
		// ...
};

When I call the method I got a error:

hello().PrintHelloWorld();

> Error: LNK2019 unresolved external symbol "public: void __thiscall Hello::PrintHelloWorld(void)" (?PrintHelloWorld@Hello@@QAEXXZ) referenced in function _main demo .\Peyman\source\repos\demo\demo\demo.obj 1

In fact, I use an SDK with no implementation and it causes the error. Please check is there any implementation or not. void PrintHelloWorld(){} with brackets

For me the problem was SDL as well. I moved
// Tell SDL not to mess with main() and #define SDL_MAIN_HANDLED before including the SDL libraries. And the problem seems fixed.

My context: Visual Studio

I have had the same issue when I've added an existing file with wrong extension (like *.ccc).

Than I've changed the extension to *.cpp. When I've built the solution I've got a similar link error.

I've discovered the reason when I've taken a look to *.vcxproject file. The file has not been identified by Visual Studio as source file so it put it to ClInclude group (see below).

    <ItemGroup>
        <ClInclude Include="toto.cpp" />
    </ItemGroup>

I move it to ClCompile group (see below) and rebuild without error.

    <ItemGroup>
        <ClCompile Include="AnotherSource.cpp" />
        <ClCompile Include="toto.cpp" />
    </ItemGroup>

go to "Project-Properties-Configuration Properties-Linker-input-Additional dependencies" then go to the end and type ";ws2_32.lib".

try using return 0;

if it keeps failing change your solution platform to 64x instead of 86x and go to configuration manager(that's were you change the 86x to 64x) and in platform set it to 64 bits

that works for me, hope it work to you