Share via


Unresolved external "int __cdecl invoke_main(void)" after VS2017 15.6.1 update

Question

Monday, March 12, 2018 11:27 PM

Hello all,

I hope someone can help/guide me here. I had a working application, but today I keep getting the following error:

LNK2019 unresolved external symbol main referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)

The only thing that changed was that I updated VS2017 15.5.4 to VS2017 15.6.1 (latest). I been reading here and there, and I believe somewhere some setting may have changed and now the program is failing to "see" the main function. For the record, I did try this code in my laptop which still has VS2017 15.5.4 and ran without any issues. Any idea what it may be? Thanks in advance.

All replies (5)

Monday, March 12, 2018 11:45 PM

I can build a console application without any issues with Visual Studio 2017 15.6.1, tested just before I started writing this.

One thing to try, if you just create a new console application, just using the basic Windows Console Application template, does it build successfully?

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.


Tuesday, March 13, 2018 12:35 AM

Yes, I can start a new project using the template and run without any issues. 


Tuesday, March 13, 2018 4:31 PM | 1 vote

I was looking into this a little, and it is surprisingly hard to trigger this. The only compiler option that I know of that could affect this is the calling convention option, but the compiler protects against this. If you modify the calling convention option on a source file with main in, the compiler ignores it and outputs the warning:

1>c:\users\darran\source\repos\meh\meh\main.cpp(8): warning C4007: 'main': must be '__cdecl'

I have been unable to find any other option with the potential of defeating the compiler's detection of main.

It is easier to get your code to defeat this detection though. Unlike the command line option, if you explicitly change the function's calling convention, then the function will no longer be detected. There is also putting main into a namespace.

Trying to mark main as extern"C++" doesn't work though.

The only other thing that have any effect is if the source file is being compiled. So check if it is in the compiler output, or go to the directory where the objects are being written to and look for it there.

Besides these, I don't know if there are any other things that could affect the project. You could always add a source file and add a dummy main to the project to see if the linker picks that one up. If it does, then you would have to focus on what would cause the linker not to find main. This dummy main function is only temporary though.

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.


Tuesday, March 13, 2018 6:33 PM | 1 vote

Is your main function called _tmain? Then make sure that <tchar.h> is correctly included.


Monday, March 26, 2018 2:18 AM

Hi Velchivz,

What about this issue in your side? Do you resolve this issue?

Maybe like this thread, please check your project property for the project type, and also check your main function:

https://social.msdn.microsoft.com/Forums/en-US/21e3585f-bb5f-498e-805d-d09ad9f6f557/main-program-is-listed-as-unresolved-symbol?forum=vcgeneral

Any update, feel free to share it here.

Best Regards,

Jack

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.