应该#define GLUT_DISABLE_ATEXIT_HACK吗? C ++

时间:2014-03-17 12:35:23

标签: c++ opengl

我使用MinGW64eclipse来编译FreeGLUT示例程序。 我收到以下错误。

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

信息:内部构建器用于构建 g ++" -ID:\ ... \ 3rdPartyLibraries \ freeglut \ include" " -ID:\ ... \ 3rdPartyLibraries \ freeglut \ lib中\ 64" -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 to imp _glutInitWithExit' src \ LUtil.o:在函数glutCreateWindow_ATEXIT_HACK': D:/.../3rdPartyLibraries/freeglut/include/GL/freeglut_std.h:622: undefined reference to imp _glutCreateWindowWithExit' src \ LUtil.o:在函数glutCreateMenu_ATEXIT_HACK': D:/.../3rdPartyLibraries/freeglut/include/GL/freeglut_std.h:624: undefined reference to imp _glutCreateMenuWithExit' collect2.exe:错误:ld返回1退出状态

所以我搜索了标题并找到freeglut_std.h

  

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

     

Win32有一个烦人的问题,即有多个C运行时     图书馆(CRT)。如果可执行文件与不同的CRT链接     从GLUT DLL,GLUT DLL将不会共享相同的CRT静态     可执行文件看到的数据。特别是,注册了atexit回调     如果GLUT调用它(不同),则不会调用可执行文件     退出常规)。 GLUT通常是用     " / MD"选项(具有多线程DLL支持的CRT),但Visual     C ++链接器默认为" / ML" (单线程CRT)。

     

此问题的一个解决方法是要求用户始终链接     与GLUT编译的CRT相同。这需要用户提供     非标准选择。 GLUT 3.7有自己的内置解决方法     可执行文件"退出"函数指针被秘密传递给GLUT。     然后GLUT调用可执行文件的退出函数指针来确保     任何" atexit"如果是GLUT,则调用应用程序注册的调用     需要退出。

     

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

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

所以我遇到的问题是:"这是我应该做的,还是仅仅是一种解决其他地方应该修复的错误方法?"

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

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

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

0 个答案:

没有答案