undefined reference to `[email protected]'

Question

When I try to build a program using Eclipse CDT, I get the following:

/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x106): undefined reference to `[email protected]

Why is that? And, how can I solve this issue?

Solution 1

This error occurs when the linker can't find WinMain function, so it is probably missing. In your case, you are probably missing main too.

Consider the following Windows API-level program:

#define NOMINMAX
#include <windows.h>
int main()
{
    MessageBox( 0, "Blah blah...", "My Windows app!", MB_SETFOREGROUND );
}

Now let's build it using GNU toolchain (i.e. g++), no special options. Here gnuc is just a batch file that I use for that. It only supplies options to make g++ more standard:

C:\test> gnuc x.cpp
C:\test> objdump -x a.exe | findstr /i "^subsystem"
Subsystem               00000003        (Windows CUI)
C:\test> _

This means that the linker by default produced a console subsystem executable. The subsystem value in the file header tells Windows what services the program requires. In this case, with console system, that the program requires a console window.

This also causes the command interpreter to wait for the program to complete.

Now let's build it with GUI subsystem, which just means that the program does not require a console window:

C:\test> gnuc x.cpp -mwindows
C:\test> objdump -x a.exe | findstr /i "^subsystem"
Subsystem               00000002        (Windows GUI)
C:\test> _

Hopefully that's OK so far, although the -mwindows flag is just semi-documented.

Building without that semi-documented flag one would have to more specifically tell the linker which subsystem value one desires, and some Windows API import libraries will then in general have to be specified explicitly:

C:\test> gnuc x.cpp -Wl,-subsystem,windows
C:\test> objdump -x a.exe | findstr /i "^subsystem"
Subsystem               00000002        (Windows GUI)
C:\test> _

That worked fine, with the GNU toolchain.

But what about the Microsoft toolchain, i.e. Visual C++?

Well, building as a console subsystem executable works fine:

C:\test> msvc x.cpp user32.lib
x.cpp
C:\test> dumpbin /headers x.exe | find /i "subsystem" | find /i "Windows"
               3 subsystem (Windows CUI)
C:\test> _

However, with Microsoft's toolchain building as GUI subsystem does not work by default:

C:\test> msvc x.cpp user32.lib /link /subsystem:windows
x.cpp
LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol [email protected] referenced in function ___tmainCRTStartu
p
x.exe : fatal error LNK1120: 1 unresolved externals
C:\test> _

Technically this is because Microsoft’s linker is non-standard by default for GUI subsystem. By default, when the subsystem is GUI, then Microsoft's linker uses a runtime library entry point, the function where the machine code execution starts, called winMainCRTStartup, that calls Microsoft's non-standard WinMain instead of standard main.

No big deal to fix that, though.

All you have to do is to tell Microsoft's linker which entry point to use, namely mainCRTStartup, which calls standard main:

C:\test> msvc x.cpp user32.lib /link /subsystem:windows /entry:mainCRTStartup
x.cpp
C:\test> dumpbin /headers x.exe | find /i "subsystem" | find /i "Windows"
               2 subsystem (Windows GUI)
C:\test> _

No problem, but very tedious. And so arcane and hidden that most Windows programmers, who mostly only use Microsoft’s non-standard-by-default tools, do not even know about it, and mistakenly think that a Windows GUI subsystem program “must” have non-standard WinMain instead of standard main. In passing, with C++0x Microsoft will have a problem with this, since the compiler must then advertize whether it's free-standing or hosted (when hosted it must support standard main).

Anyway, that's the reason why g++ can complain about WinMain missing: it's a silly non-standard startup function that Microsoft's tools require by default for GUI subsystem programs.

But as you can see above, g++ has no problem with standard main even for a GUI subsystem program.

So what could be the problem?

Well, you are probably missing a main. And you probably have no (proper) WinMain either! And then g++, after having searched for main (no such), and for Microsoft's non-standard WinMain (no such), reports that the latter is missing.

Testing with an empty source:

C:\test> type nul >y.cpp
C:\test> gnuc y.cpp -mwindows
c:/program files/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined referen
ce to `[email protected]'
collect2: ld returned 1 exit status
C:\test> _

Solution 2

To summarize the above post by Cheers and hth. - Alf, Make sure you have main() or WinMain() defined and g++ should do the right thing.

My problem was that main() was defined inside of a namespace by accident.

Solution 3

I was encountering this error while compiling my application with SDL. This was caused by SDL defining it's own main function in SDL_main.h. To prevent SDL define the main function an SDL_MAIN_HANDLED macro has to be defined before the SDL.h header is included.

Solution 4

Try saving your .c file before building. I believe your computer is referencing a path to a file with no information inside of it.

Solution 5

My situation was that I did not have a main function.

View more solutions

Comments

[Simplicity]

@Alf P. Steinbach. Thanks so much for your nice reply. As for All you have to do is to tell Microsoft's linker which entry point to use, namely mainCRTStartup, which calls standard main. Is there a way to do that Eclipse CDT as I'm not using the command line. Thanks

[Cheers and hth. - Alf]

@user588855: since you're using g++ that (probably) does not apply to you. Only the part at the end (probably) applies. That is, define a main or a WinMain, or, make sure that the relevant file is included in the project. Cheers,

[Simplicity]

@Alf P. Steinbach. What do you mean by defining main or winmain? Thanks

[Cheers and hth. - Alf]

@user588855: the example program at the top of the answer shows a standard main function. You need that in your program (but with some other body). Or, you might use a non-standard Microsoft WinMain, but you need to have one of them, and the file needs to be included in the project.

[Jeff Muir]

Just realized something important about all this. In my case, it was not finding main() since I did not declare any arguments (argc, argv). Once added, it found main. Also, the nature of how this works means that mingw is trying to help by providing its own main which in turn calls WinMain. GUI programs would only have WinMain and the main stub in mingw is used to get there. If you have a main, then it uses that instead.

[Indeed]

I just made a file called main.cpp that had the code: int main() { }

[driedler]

extern "C" int main(void) fixed the problem for me

[8Observer8]

Thanks a lot! This command works: gcc main.c -I"E:\Libs\SDL2-devel-2.0.12-mingw\SDL2-2.0.12\i686-w64-ming‌​w32\include" -I"E:\Libs\SDL2_ttf-devel-2.0.15-mingw\SDL2_ttf-2.0.15\i686-‌​w64-mingw32\include" -L"E:\Libs\SDL2-devel-2.0.12-mingw\SDL2-2.0.12\i686-w64-ming‌​w32\lib" -L"E:\Libs\SDL2_ttf-devel-2.0.15-mingw\SDL2_ttf-2.0.15\i686-‌​w64-mingw32\lib" -lSDL2 -lSDL2main -lSDL2_ttf -o app.exe

[mariusm]

instead of -mwindows one could use -mconsole, if only CLI interface is used.

[IInspectable]

Since you asked for it: This downvote is for the misinformation sprinkled throughout this entire answer. Maybe you should resist answering Windows-specific questions until you can cope with facts (such as: GCC is no more conforming than MSVC).