PAYATHON 2026

C++ 可执行文件运行时提示 "Entry Point Not Found"

排障赵师傅

结论

问题出在程序启动时加载了与编译器不匹配的 C++ 运行库 DLL，而不是计算器代码或 main() 入口。其中很可能包括 libstdc++-6.dll，也可能涉及相应版本的 GCC 运行库。

编译后的程序需要以下符号：

_ZNKSt9basic_iosIcSt11char_traitsIcEEcvbEv

这个符号对应 std::basic_ios 的一个 C++ 成员函数，用于检查输入输出流的状态。Windows 找到的运行库 DLL 没有导出该符号，因此程序还没进入 main() 就报出了 Entry Point Not Found。

改用以下命令后，程序可以正常运行：

g++ "First Design.cpp" -o "First Design.exe" -static-libstdc++ -static-libgcc

这是因为链接器将所需的 libstdc++ 和 libgcc 代码直接写入了 .exe。程序不再需要加载系统中可能不兼容的这两类 DLL。

为什么能够编译，却不能运行

编译和运行分别依赖不同的文件：

  1. 编译和链接时，g++ 使用当前工具链中的头文件与导入库。
  2. 运行时，Windows 按照 DLL 搜索规则查找实际加载的动态库。

如果 Windows 找到了另一套 MinGW、旧版 GCC 或其他软件附带的 libstdc++-6.dll，该文件可能没有编译器要求的符号。链接阶段无法检查目标电脑最终会加载哪一份 DLL，所以程序仍能成功生成。

同一程序能在另一台电脑上运行，通常是因为那台电脑安装了匹配的运行库，或者其 PATH 中没有发生冲突的旧 DLL。

为什么错误信息会提到可执行文件

Windows 可能在错误信息中显示当前可执行文件的路径，因为无法解析的是该文件的导入项。这不表示 .exe 应该导出这个 C++ 符号，也不是 Windows 找不到 main()。

这里的“Entry Point”是 DLL 中被导入的函数入口，与 C++ 程序的 main() 函数无关。

如何确认实际依赖

先确认当前使用的编译器：

where g++
g++ --version

再查看可执行文件依赖的 DLL：

objdump -p "First Design.exe" | findstr /i "DLL Name"

MinGW 的版本或架构不同，GCC 运行库的文件名也可能不同。常见名称有：

libstdc++-6.dll
libgcc_s_seh-1.dll
libgcc_s_dw2-1.dll
libwinpthread-1.dll

程序未必依赖上面列出的所有文件，具体应以 objdump 的结果为准。

接着可以检查 PATH 中有哪些同名文件：

where libstdc++-6.dll
where libgcc_s_seh-1.dll
where libgcc_s_dw2-1.dll
where libwinpthread-1.dll

如果同一个 DLL 对应多个路径，特别是这些文件分别来自不同的 MinGW、MSYS2、Code::Blocks、Qt 或其他开发工具目录，通常说明存在版本冲突。

还要检查 "First Design.exe" 所在的目录。Windows 通常会优先查找程序目录中的 DLL，因此 .exe 旁边的旧版 DLL 可能会覆盖工具链中的正确版本。

推荐解决方法

方法一：部署同一工具链的 DLL

从当前 g++ 所属工具链的 bin 目录中取出程序实际依赖的 DLL，把它们放到 "First Design.exe" 所在目录，或者正确配置 PATH。

需要保证 g++.exe、链接时使用的库和运行时加载的 DLL 来自同一套兼容工具链。

不要从随机的 DLL 下载网站获取文件。文件名相同不代表二进制接口兼容。

方法二：清理 PATH 中的冲突

如果电脑上装有多套 GCC/MinGW 工具链，可以调整 PATH 的顺序，让目标工具链的 bin 目录排在旧版本之前。修改后重新打开命令提示符，再运行：

where g++
where libstdc++-6.dll

根据输出即可确认新的命令行环境是否使用了预期版本。

方法三：静态链接 GCC 运行库

这种简单的独立程序可以继续使用：

g++ "First Design.cpp" -o "First Design.exe" -static-libstdc++ -static-libgcc

这样更方便将程序复制到其他电脑运行，但有几点需要注意：

  • 生成的 .exe 会更大。
  • 这两个选项只会静态链接 libstdc++ 和 libgcc，不会静态链接所有依赖。
  • 程序仍可能依赖 Windows 系统 DLL，某些工具链配置也可能引入其他运行库。
  • 如果程序以后需要与其他 DLL 交换 C++ 对象、异常或标准库类型，应统一编译器和运行库配置，不能只靠静态链接避开兼容性问题。

sfc /scannow 为什么没有作用

sfc /scannow 主要用于检查和修复受 Windows 保护的系统文件。MinGW 的 libstdc++、libgcc 等 DLL 来自第三方开发工具，不属于 Windows 自带的 C++ 运行库。

除非系统文件本身也有损坏，否则运行 sfc /scannow 无法解决 MinGW DLL 的版本冲突。

与源代码及头文件的关系

这类加载错误并非由计算器代码本身引起。报错符号属于标准输入输出流的实现，而程序使用了：

cin >> current;

while (cin >> op >> next) {
    // ...
}

编译器会为这些操作生成对 libstdc++ 的调用。报错的原因是这些调用要求的 ABI 与程序运行时实际加载的 DLL 不一致。

std_lib_facilities.h 可能影响程序使用哪些标准库功能。只要它与当前编译环境兼容，就不会直接导致这次 Entry Point Not Found。解决问题仍要从编译器、链接库以及运行时 DLL 的版本和架构是否一致入手。

备注：内容仅供参考。