錯誤1：如下藍色部分表示：這是變量的定義位置不正確造成的，需要把變量name定義在函數的開頭部分。因爲有些編譯器要求變量必須定義在函數 的開頭。
2.使用glGetString(GL_VERSION)函數的返回值是null，原因是在使用opengl函數之前，要先初始化渲染的上下文（rending text），在這裏的解決方法是，在調用此函數前，要先調用glutInit()和glutCreateWindow()函數。
錯誤3：error C2381: ‘exit’ : redefinition; __declspec(noreturn) differs
solution:
#include "stdlib.h"//(請把 " 號換成破折號) #include "glut.h"//(請把 " 號換成破折號)
出現error的原因可能是以下幾種
i） 少了stdlib.h
ii） 順序倒了
錯誤4：Error: argument of type ‘const char*’ is incompatible with parameter of type ‘LPCWSTR’
即：const char to LPCTSTR不能轉化問題，以前在寫DX時，好像也遇到過
Visual C++ 2008裏cannot convert parameter 1 from ‘const char [13]‘ to ‘LPCTSTR’造成不能運行的原因主要是2005和2008中增加了一些參數類型的安全性檢查，所以通常在6.0沒有問題的LPCTSTR與 const char之間的轉換到了這裏就玩不轉。微軟給出的解決辦法有兩個：
Change your project configuration to use multibyte strings. Press ALT+F7 to open the properties, and navigate to Configuration Properties > General. Switch Character Set to “Use Multi-Byte Character Set”.
Indicate that the string literal, in this case “Hello world!” is of a specific encoding. This can be done through either prefixing it with L, such as L”Hello world!”, or surrounding it with the generic _T(“Hello world!”) macro. The latter will expand to the
L prefix if you are compiling for unicode (see #1), and nothing (indicating multi-byte) otherwise.
但是如果是變量，不是常量字符串的話，就還是會有問題。最痛快的辦法就是在建立工程時，直接選不用那個Use Unicode libraries ，這樣就不會再遇到這個問題了。
錯誤5：MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup
原因是我把 int WINAPI WinMain 寫成了int WINAPI winMain，即WinMain小寫了，於是鏈接庫找不到啓動入口函數。
原來在windows編程中，WinMain 是大小寫都定死的函數死，這一點與win32彙編不同，呵呵。
錯誤6：error LNK2019: unresolved external symbol _auxDIBImageLoadA@4 referenced in function “struct _AUX_RGBImageRec * __cdecl LoadBMP(char *)” (?LoadBMP@@YAPAU_AUX_RGBImageRec@@PAD@Z)
原因是auxDIBImageLoad方法是由glaux.lib庫提供的，並由glaux.h聲明。
解決方法：下載全的庫，然後在工程中顯式鏈接這個庫
project->property->Linker->Input->Add Dependencies 添加OPENGL32.LIB;GLU32.LIB;glut.lib;glaux.lib
錯誤7：Win32窗口無法顯示出來？
90% 是 LRESULT CALLBACK wndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); 函數的消息處理分支邏輯不正確，比如：(當這種情況發生時，最快的排錯法子是：用beyong compare來比較文本)
...
case WM_SIZE: {
resizeGLScence(LOWORD(lParam),HIWORD(lParam));
return 0;
}
}
return DefWindowProc(hWnd,uMsg,wParam,lParam);
}
寫成了：
...
case WM_SIZE: {
resizeGLScence(LOWORD(lParam),HIWORD(lParam));
return 0;
}
return DefWindowProc(hWnd,uMsg,wParam,lParam);
}
}
8.無法定位程序輸入點_glewInit@0於動態鏈接庫glew32.dll
在使用cmake編譯freetype-gl後，使用vs2010運行程序出現”無法定位程序輸入點_glewInit@0於動態鏈接庫glew32.dll“,原因是cmake使用程序中帶的glew32.lib庫進行鏈接，但是運行時用的是windows中的動態鏈接庫glew32.dll進行鏈接。而這個是我自己下載的glew32.dll，不是程序中帶有的glew32.dll，由於兩個版本不相同。導致了定位錯誤。將程序中的glew32.lib對應的glew32.dll替換system32/systemW64中的glew32.dll即可