总之，使用glew的dll版本没有真正的好处

In all honesty, there is no real benefit to using the DLL version of glew (short of reduced executable size, but this hardly matters on modern Windows PCs).

这不是你可以简单地将一个新版本的DLL放入你的应用程序，并使用以前从未使用过的扩展。同样，对于基本上只解析扩展规范的库，错误修复非常罕见/不必要。使用DLL作为固定扩展加载错误在装运软件的手段的文件也不实用。从长远来看，静态链接到glew（这意味着 glew32s.lib ）更有意义。

It is not like you can simply drop a new version of the DLL into your application and use extensions that you never used before. Likewise, bug fixes are so infrequent/unnecessary with a library that basically just parses the extension spec. files that using the DLL as a means of fixing extension loading bugs in shipped software is also not practical. Statically linking to glew (this means glew32s.lib) makes much more sense in the long run.

链接库在Windows上也更加可移植，它将与MSVC和MinGW（而DLL库只适用于MSVC）一起工作。链接 glew32s ，并把它放在你决定用于附加库依赖的任何目录。

---

这是我写的使用glew的项目的一个示例解决方案配置。我已经为这种特定软件建立了约定，其中编译时依赖性存储在 platform /< Subsystem> 下。因此，我在 glew32s.lib （32位）和 glew64s.lib > ./ Epsilon / platform / OpenGL / glew {32 | 64} s.lib

The static linking library is also more portable on Windows, it will work with MSVC and MinGW (whereas the DLL library only works with MSVC). Link against glew32s and put that in whatever directory you decided to use for additional library dependencies.

---

Here is a sample solution configuration for a project I wrote that uses glew. I have established a convention for this particular software where compile-time dependencies are stored under platform/<Subsystem>. Thus, I have glew32s.lib (32-bit) and glew64s.lib (64-bit) in ./Epsilon/platform/OpenGL/glew{32|64}s.lib