坑爹的gltools编译错误解决

搭边手游，看opengl superbible， 书中代码需要一个gltools库。作者自己提供的code google地址里gltools项目是空的，此一坑。

他的网站(www.starstonesoftware.com)关于opengl的页面打不开，此二坑。

好不容易github拖到一个，需要用到freeglut和glew。都准备就绪了，编译出错，link2001和link2019，均跟glew有关。仔细检查glew的c++选项和链接选项，glew的MT改为MD，此外保证gltools的其他选项与glew相同，编之，不通，但错误减少了，此三坑。

此时去编它的静态库，通过了。本不想理会了，无奈较劲上了，继续查。发现gltools的glbatch.h文件里，定义了GLEW_STATIC。故而我们静态版本通过了，但编动态库版本对于glew的c方式导出全部少了正确修饰符，GLEWAPI没被定义为extern __declspec(dllimport)。把该文件的GLEW_STATIC删除。仍没通过。此四坑。

然后发现这个cmake生成的gltools工程，另外几个重要的头文件没被直接添加在工程里，故而我全局查找GLEW_STATIC时漏了这几个文件，而它们全部都定义了这个宏。好在也不多，全部删除之。此五坑。

仍不通过，剩下的是opengl本身函数的链接问题，这你都没加上，太坑了吧。把opengl链接添上，动态库版本总算好了。此六坑。

然后才发现gltools本身没加dll修饰符，没导出类和函数，算我无用功了。原本就是static版本省心，此七坑。

说到底还是跟windows过不去的原因。我人很懒，因此向来不喜欢linux，矛盾的很。

都说这本书比较靠谱，我说这作者们，6,7百页的书您们都写了，还到了第五版（英文到六了吧），叫几个手下帮你做做这项目工程总可以吧。像这类书针对该都是尚不熟悉opengl甚至编程的读者，其实能有一个方便傻瓜直接跑的工程对他们很重要。估计很多人就卡在上边没心情了。