Error Lnk2019: Unresolved External Symbol _Main Referenced in Function _Tmaincrtstartup, But This Time It's Not a Windows/Console Problem!

error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup, but this time it's NOT a Windows/Console problem!

SDL_main.h is included automatically from SDL.h, so you always get the nasty #define.

Just write:

#include <SDL.h>
#undef main

And it should work fine

LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

What is your project type? If it's a "Win32 project", your entry point should be (w)WinMain. If it's a "Win32 Console Project", then it should be (w)main. The name _tmain is #defined to be either main or wmain depending on whether UNICODE is defined or not.

If it's a DLL, then DllMain.

The project type can be seen under project properties, Linker, System, Subsystem. It would say either "Console" or "Windows".

Note that the entry point name varies depending on whether UNICODE is defined or not. In VS2008, it's defined by default.

The proper prototype for main is either

int _tmain(int argc, _TCHAR* argv[])

or

int _tmain()

Make sure it's one of those.

EDIT:

If you're getting an error on _TCHAR, place an

#include <tchar.h>

If you think the issue is with one of the headers, go to the properties of the file with main(), and under Preprocessor, enable generating of the preprocessed file. Then compile. You'll get a file with the same name a .i extension. Open it, and see if anything unsavory happened to the main() function. There can be rogue #defines in theory...

EDIT2:

With UNICODE defined (which is the default), the linker expects the entry point to be wmain(), not main(). _tmain has the advantage of being UNICODE-agnostic - it translates to either main or wmain.

Some time ago, there was a reason to maintain both an ANSI build and a Unicode build. Unicode support was sorely incomplete in Windows 95/98/Me. The primary APIs were ANSI, and Unicode versions existed here and there, but not pervasively. Also, the VS debugger had trouble displaying Unicode strings. In the NT kernel OSes (that's Windows 2000/XP/Vista/7/8/10), Unicode support is primary, and ANSI functions are added on top. So ever since VS2005, the default upon project creation is Unicode. That means - wmain. They could not keep the same entry point name because the parameter types are different. _TCHAR is #defined to be either char or wchar_t. So _tmain is either main(int argc, char **argv) or wmain(int argc, wchar_t **argv).

The reason you were getting an error at _tmain at some point was probably because you did not change the type of argv to _TCHAR**.

If you're not planning to ever support ANSI (probably not), you can reformulate your entry point as

int wmain(int argc, wchar_t *argv[])

and remove the tchar.h include line.

error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

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.

Error: Error 1 error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup

Set your sub system to console instead of windows, or add the winmain function as your entry point.

See: http://msdn.microsoft.com/en-us/library/fcc1zstk.aspx

And:

difference between Console (/SUBSYSTEM:CONSOLE) and Windows (/SUBSYSTEM:WINDOWS)

LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup with DLLs

Almost four years later I finally revisited this issue and after going through all object files to see which one was the culprit I finally found the error in src/SDL.c. It has these lines at the end:

#if defined(__WIN32__)

#if !defined(HAVE_LIBC) || (defined(__WATCOMC__) && defined(BUILD_DLL))
/* Need to include DllMain() on Watcom C for some reason.. */

BOOL APIENTRY
_DllMainCRTStartup(HANDLE hModule,
                   DWORD ul_reason_for_call, LPVOID lpReserved)
{
    switch (ul_reason_for_call) {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}
#endif /* building DLL with Watcom C */

#endif /* __WIN32__ */ 

So SDL always defined a _DllMainCRTStartup symbol which seems to have confused the linker and led to the error shown in the OP. Killing the code above (or defining HAVE_LIBC) finally solves the problem and I can build SDL2 just fine with /MT (though I still don't know why compiling with /MD didn't cause any problems because AFAICS _DllMainCRTStartup will also be defined when compiling with /MD but it doesn't seem to cause any harm in that case).

Issue solved, finally.

How can I solve the error LNK2019: unresolved external symbol - function?

One option would be to include function.cpp in your UnitTest1 project, but that may not be the most ideal solution structure. The short answer to your problem is that when building your UnitTest1 project, the compiler and linker have no idea that function.cpp exists, and also have nothing to link that contains a definition of multiple. A way to fix this is making use of linking libraries.

Since your unit tests are in a different project, I'm assuming your intention is to make that project a standalone unit-testing program. With the functions you are testing located in another project, it's possible to build that project to either a dynamically or statically linked library. Static libraries are linked to other programs at build time, and have the extension .lib, and dynamic libraries are linked at runtime, and have the extension .dll. For my answer I'll prefer static libraries.

You can turn your first program into a static library by changing it in the projects properties. There should be an option under the General tab where the project is set to build to an executable (.exe). You can change this to .lib. The .lib file will build to the same place as the .exe.

In your UnitTest1 project, you can go to its properties, and under the Linker tab in the category Additional Library Directories, add the path to which MyProjectTest builds. Then, for Additional Dependencies under the Linker - Input tab, add the name of your static library, most likely MyProjectTest.lib.

That should allow your project to build. Note that by doing this, MyProjectTest will not be a standalone executable program unless you change its build properties as needed, which would be less than ideal.

---

Related Topics