应该#define GLUT_DISABLE_ATEXIT_HACK吗？C++

Question

我用MinGW64它eclipse来编译一个FreeGLUT示例程序.我收到以下错误.

11:55:58 **** Incremental Build of configuration Debug for project OpenGL ****

信息:内部构建器用于构建g ++"-ID:\ ...\3rdPartyLibraries\freeglut\include"" - ID:\ ...\3rdPartyLibraries\freeglut\lib\x64"-O0 -g3 -Wall -c - fmessage-length = 0 -std = c ++ 11 -o"src\LUtil.o""..\src\LUtil.cpp"g ++"-LD:\ ...\3rdPartyLibraries\freeglut\lib\x64" - o OpenGL.exe"src\cPoint.o""src\OpenGL.o""src\LUtil.o"-lglu32 -lfreeglut_static -lopengl32 -lwinmm -lgdi32 src\LUtil.o:在函数glutInit_ATEXIT_HACK': D:/.../3rdPartyLibraries/freeglut/include/GL/freeglut_std.h:620: undefined reference toimp _glutInitWithExit'src\LUtil中. o:在函数glutCreateWindow_ATEXIT_HACK': D:/.../3rdPartyLibraries/freeglut/include/GL/freeglut_std.h:622: undefined reference toimp _glutCreateWindowWithExit'src\LUtil.o中:在函数glutCreateMenu_ATEXIT_HACK': D:/.../3rdPartyLibraries/freeglut/include/GL/freeglut_std.h:624: undefined reference toimp _glutCreateMenuWithExit'cols2.exe:error:ld返回1退出状态

所以我搜索了标题并发现freeglut_std.h:

/*来自经典GLUT的glut.h的评论:

Win32有一个恼人的问题,其中有多个C运行时库(CRT).如果可执行文件与GLUT DLL中的不同CRT链接,则GLUT DLL将不共享可执行文件看到的相同CRT静态数据.特别是,如果GLUT调用其(不同的)退出例程,则不会调用可执行文件中注册的atexit回调.GLUT通常使用"/ MD"选项(具有多线程DLL支持的CRT)构建,但Visual C++链接器默认为"/ ML"(单线程CRT).

此问题的一个解决方法是要求用户始终使用与编译GLUT相同的CRT进行链接.这要求用户提供非标准选项.GLUT 3.7有自己的内置解决方法,可执行文件的"exit"函数指针被隐式传递给GLUT.然后,GLUT调用可执行文件的exit函数指针,以确保在GLUT需要退出时调用应用程序注册的任何"atexit"调用.

请注意,不应直接调用__glut*WithExit例程.为了避免atexit解决方法,#define GLUT_DISABLE_ATEXIT_HACK.*/

我没有得到技术细节,但显然有一个选项可以禁用它.即#define GLUT_DISABLE_ATEXIT_HACK.使用此定义时,错误消息消失并编译.

因此,我遇到的问题是:"这是我应该做的,还是只是一种解决其他问题的坏方法？"

由于我缺乏信息学背景,我不太了解这个"退出问题"的含义和解决方法.我想到的是,解决方法可能是有充分理由的,因此禁用它可能不明智.那么设置定义处理此错误的正确方法,还是仅仅掩盖应该在其他地方修复的问题的影响？

我的问题基本上归结为:"我应该使用#define GLUT_DISABLE_ATEXIT_HACK还是有其他/更好的方法来解决这个问题？"

另外,如果你能让我了解这个理论背景,我会感兴趣.