未定义对“WinMain@16”的引用

Question

当我尝试使用Eclipse CDT构建程序时，我得到以下信息：

/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x106): 未定义引用`WinMain@16

这是为什么？ 而且，我该如何解决这个问题？

Answer 1

当链接器找不到WinMain函数时会发生此错误，因此它可能丢失了。 在您的情况下，您可能也缺少main 。

考虑以下 Windows API 级程序：

#define NOMINMAX
#include <windows.h>

int main()
{
    MessageBox( 0, "Blah blah...", "My Windows app!", MB_SETFOREGROUND );
}

现在让我们使用 GNU 工具链（即 g++）构建它，没有特殊选项。 这里的gnuc只是我用来做的一个批处理文件。 它只提供使 g++ 更标准的选项：

C:\test> gnuc x.cpp

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

C:\test> _

这意味着链接器默认生成一个控制台子系统可执行文件。 文件头中的子系统值告诉 Windows 程序需要什么服务。 在这种情况下，使用控制台系统，该程序需要一个控制台窗口。

这也会导致命令解释器等待程序完成。

现在让我们用GUI 子系统构建它，这意味着程序不需要控制台窗口：

C:\test> gnuc x.cpp -mwindows

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

C:\test> _

希望到目前为止一切正常，尽管-mwindows标志只是半记录的。

如果没有该半文档化标志，则必须更具体地告诉链接器需要哪个子系统值，然后通常必须明确指定一些 Windows API 导入库：

C:\test> gnuc x.cpp -Wl,-subsystem,windows

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

C:\test> _

使用 GNU 工具链，效果很好。

但是Microsoft 工具链，即Visual C++ 呢？

好吧，构建为控制台子系统可执行文件可以正常工作：

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> _

但是，默认情况下，Microsoft 将工具链构建为 GUI 子系统不起作用：

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

C:\test> _

从技术上讲，这是因为 Microsoft 的链接器默认情况下对于 GUI 子系统是非标准的。 默认情况下，当子系统为 GUI 时，Microsoft 的链接器使用运行时库入口点，即机器代码执行开始的函数，称为winMainCRTStartup ，它调用 Microsoft 的非标准WinMain而不是标准main 。

不过，解决这个问题没什么大不了的。

你所要做的就是告诉微软的链接器使用哪个入口点，即mainCRTStartup ，它调用标准的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> _

没问题，但非常乏味。 如此神秘和隐藏，以至于大多数只使用微软默认的非标准工具的大多数 Windows 程序员甚至都不知道它，并错误地认为 Windows GUI 子系统程序“必须”有非标准的WinMain而不是标准main 。 顺便说一句，对于 C++0x，微软会遇到这个问题，因为编译器必须宣传它是独立的还是托管的（托管时它必须支持标准main ）。

无论如何，这就是 g++可以抱怨WinMain缺失的原因：这是一个愚蠢的非标准启动功能，微软的工具默认需要 GUI 子系统程序。

但正如您在上面看到的，即使对于 GUI 子系统程序，g++ 对标准main也没有问题。

那么可能是什么问题呢？

好吧，您可能缺少一个main 。 而且您可能也没有（正确的） WinMain ！ 然后 g++，在搜索了main （没有这样的）和微软的非标准WinMain （没有这样的）之后，报告后者丢失了。

使用空源进行测试：

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 `WinMain@16'
collect2: ld returned 1 exit status

C:\test> _

Answer 2

总结 Cheers 和 hth 的上述帖子。 - Alf，确保你定义了main()或WinMain()并且 g++ 应该做正确的事情。

我的问题是main()是偶然在命名空间内定义的。

Answer 3

我在使用 SDL 编译我的应用程序时遇到了这个错误。 这是由 SDL 在 SDL_main.h 中定义它自己的 main 函数引起的。 为了防止 SDL 定义主函数，必须在包含 SDL.h 头文件之前定义 SDL_MAIN_HANDLED 宏。

Answer 4

尝试在构建之前保存您的 .c 文件。 我相信您的计算机正在引用一个文件的路径，其中没有任何信息。

"

Answer 5

我的情况是我没有 main 函数。

Answer 6

有同样的问题。 为了修复它，我在构建之前单击了保存以保存我的 .c 文件。 我相信我的计算机正在引用一个文件的路径，其中没有任何信息。

"

Answer 7

检查所有文件是否包含在您的项目中：<\/strong>

更新 cLion 后，我弹出了同样的错误。 经过数小时的修补，我注意到我的一个文件未包含在项目目标中。 将其添加回活动项目后，我停止获取对 winmain16 的未定义引用，并且代码已编译。

编辑：检查 IDE 中的构建设置也是值得的。

（不确定此错误是否与最近更新了 IDE 有关 - 可能是因果关系或只是相关的。请随时评论有关该因素的任何见解！）<\/em>