简体   繁体   中英

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!

如果您的项目中有_tmain函数,则需要include <tchar.h>.

您需要一个main()函数,以便程序知道从哪里开始。

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.

您似乎没有 main 函数,它应该是您程序的入口点。

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() #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>

转到“项目-属性-配置属性-链接器-输入-附加依赖项”,然后转到最后并键入“;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

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM