Visual Studio 2012 - 错误 LNK1104：无法打开文件 'glew32.lib'答案

【问题标题】：Visual Studio 2012 - error LNK1104: cannot open file 'glew32.lib'Visual Studio 2012 - 错误 LNK1104：无法打开文件 'glew32.lib'
【发布时间】：2014-01-01 21:12:49
【问题描述】：

我在 VS 2012 上编译基本 openGL 程序时遇到问题。编译时出现构建错误：

1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'

我按照 GLEW 文档中的说明进行操作。

在您的 OpenGL 项目中打开项目 -> 属性 -> 配置属性 -> 链接器 -> 输入 -> 附加依赖项 -> 添加 glew32.lib。

您还必须在来源中包含#include；为您的 glew 文件夹添加路径：项目 -> 属性 -> 配置属性 -> 常规 -> VC++ 目录 -> 包括目录和库目录；

C/C++ 选项卡 -> 常规 -> 附加包含目录 - 在此处添加 lib 文件夹

我还将 glew32.dll 与可执行文件一起添加到我的项目文件夹中的调试文件夹中。到目前为止，我一直收到此错误。

如果您需要进一步说明我所做的步骤，请随时询问

【问题讨论】：

我不知道如何格式化报价 - 如果版主可以为我解决这个问题
如果您临时将.lib 文件复制到某个现有的有效目录，例如$(WindowsSdkDir)\lib，会发生什么情况？
你有 glew32.lib 吗？
Linker Tools Error LNK1104 列出了许多可能的原因。你能把它们全部消灭吗？
Visual Studio error: LNK1104: cannot open file 'kernel32.lib' - only in WP8 projects / Win32 builds的可能重复

标签： c++ opengl visual-studio-2012 glew

【解决方案1】：

老实说，使用 DLL 版本的 glew 并没有真正的好处（没有减小可执行文件大小，但这在现代 Windows PC 上几乎不重要）。

这不像您可以简单地将新版本的 DLL 放入您的应用程序并使用您以前从未使用过的扩展。同样，对于一个基本上只解析扩展规范的库，错误修复是如此罕见/不必要。使用 DLL 作为修复随附软件中扩展加载错误的方法的文件也是不切实际的。从长远来看，静态链接到 glew（这意味着 glew32s.lib）更有意义。

静态链接库在 Windows 上也更易于移植，它可以与 MSVC 和 MinGW 一起使用（而 DLL 库仅适用于 MSVC）。链接 glew32s 并将其放在您决定用于其他库依赖项的任何目录中。

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

【讨论】：

我在 GLEW 1.10 包中只有 glew32（没有 s）。当您的意思是“静态”链接到 GLEW 时，您能详细说明一下吗？
@BDillan：GLEW 有两个版本。有 DLL（动态）版本，然后是在您编译/链接它时完全内置到您的软件中的版本（静态）。我总是从源代码编译 glew，但二进制存档 here 包含以下动态和静态库：lib/Release/Win32（32 位）和 lib/Release/x64（64 位）。它对 Win32 和 x64 都使用名称 glew32，对于我的软件，我实际上重命名了 64 位版本，如您在我列出的图表中所见。

【解决方案2】：

在另一个项目中使用类的步骤（添加标头和求解器链接器错误）

为了能够从另一个项目添加头文件，首先转到“属性> c++ > 常规> 附加包含目录” 并添加包含头文件的目录。现在您将能够从其他项目添加类的标题，但运行该项目仍会导致链接器错误。
在您用于其他项目的类之前添加 __declspec(dllexport)。这可以添加到该类的头文件中。这应该在函数或变量或类名之前添加。现在您将获得一个 lib 文件。（如果放错地方，你会得到这个警告：https://msdn.microsoft.com/en-us/library/eehkcz60.aspx）
“属性 > 链接器 > 其他库目录”。指定生成的 lib 文件的位置。
“Properties > Linker > Input > Additional Dependencies”：添加 lib 文件的名称。

【讨论】：

【解决方案3】：

这听起来像是已将库指定为依赖项，但链接器/附加搜索路径尚未设置为包含库所在的目录。

This may help.

【讨论】：

【解决方案4】：

在这种情况下发生在我身上，我清理了解决方案并重新构建它，然后出现了许多像 LNK1104 这样的错误。

尝试重新启动 IIS 后，我成功构建了解决方案，没有出现 LNK1104 错误。我不知道为什么，但是重新启动 IIS 比正常需要更多的时间，所以我猜其他 IIS 工作进程使用了一些东西。

试一试，看看这个魔法是否会发生在你身上。

【讨论】：

【解决方案5】：

这个问题很老并且标记为已解决，但我有类似的问题症状，但解决方案完全不同。所以以防万一其他人在这里绊倒：
似乎因为我在一个解决方案下有 2 个项目（一个 dll 和一个 exe），所以构建顺序是混合的（来自输出窗口）：

1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp

等等。根据您复制的消息，您似乎在一个解决方案下也有多个项目。一个项目正在寻找另一个构建尚未创建的 *.lib 文件。
解决方案：
右键单击“主”项目->构建依赖项->项目依赖项..->标记主要依赖于哪个项目。

【讨论】：