Visual Studio：LINK：致命错误LNK1181：无法打开input文件
我已经有一段时间在Visual Studio 2010中遇到了一个奇怪的错误。
我有一个解决scheme，包括一个编译为静态库的项目，另一个非常简单但依赖于这个库的项目。
有时候，在最后几天，重build解决scheme或者仅仅使用1-3修改源文件编译后，出现以下错误：
2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib' ========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ========== 编译thelibrary.lib是成功的，没有任何错误或警告。
我已经尝试清理解决scheme，但这并不总是奏效。
- 这里有什么问题？
在链接器（通常为附加的库目录）中，将目录添加到链接器中包含的.dll或.libs中。 如果你把它放在VC ++目录，库目录中，这是行不通的。
去：
Project properties -> Linker -> General -> Link Library Dependencies set No.
我只能看到这里发生的一件事情：在你的项目中，你没有正确设置library.lib的依赖关系，这意味着library.lib是以错误的顺序构build的（或者如果你有更多的CPU构buildconfiguration，这也可以解释错误的随机性）。 （您可以更改项目依赖项：菜单 – >项目 – >项目依赖项）
我最近遇到了同样的错误。 一些挖掘提出了这个： http : //support.microsoft.com/kb/815645
基本上，如果你在.lib的path中有空格，那很糟糕。 不知道这是怎么回事，但似乎合理可能。
解决方法是1）将lib引用放在“引号”中，或者2）将lib的path添加到您的库目录（configuration属性>> VC ++目录）。
我在VS 2010和VS 2012中都遇到了同样的问题。在我的系统上，第一个静态库被构build，然后在主项目开始构build时被立即删除。
问题是几个项目的通用中间文件夹。 只为每个项目分配单独的中间文件夹。
在这里阅读更多
我遇到了一个类似的问题，那就是在作为项目本身的一部分的.OBJ文件上发生了LINK1181错误（整个项目中只有2个.cxx文件）。
最初，我已经安装了项目，在Visual Studio中生成.EXE ，然后在Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Type ，我将.EXE更改为.DLL。 怀疑Visual Studio 2008有些困惑，我从头开始重新使用.DLL模式重新创build整个解决scheme。 之后问题就消失了。 我想如果你通过.vcproj和其他相关文件手动select你的方式，你可以找出如何解决的事情，而不是从头开始（但我的程序包含两个.cpp文件，所以它更容易重新开始）。
我解决了以下问题：
转到查看 – >属性页面 – >configuration属性 – >链接器 – >input
在其他依赖项下添加thelibrary.lib。 不要使用任何报价。
我陷入了同样的问题。 对我来说，这似乎是由两个具有相同名称的项目引起的，一个取决于另一个。
例如，我有一个名为Foo的项目，它生成Foo.lib。 然后我有另一个项目，也被命名为Foo，它产生Foo.exe和Foo.lib中的链接。
我看了文件活动w /进程监视器。 似乎发生的事情是Foo（lib）首先被build立 – 这是正确的，因为Foo（exe）被标记为依赖于Foo（lib）。 这一切都很好，并成功build立，并放置在输出目录 – $（OutDir）$（TargetName）$（TargetExt）。 然后Foo（exe）被触发重build。 那么，重build是一个清洁，然后构build。 看起来Foo.exe的“干净”阶段是从输出目录中删除Foo.lib。 这也解释了为什么后续的“构build”工作 – 这不会删除输出文件。
VS中的一个错误，我猜。
不幸的是，由于涉及重build问题，我无法解决问题。 解决方法是手动发出清洁，然后生成。
我不知道为什么，但将Linker-> Input-> Additional Dependencies引用从“dxguid.lib”更改为“C：\ Program Files（x86）\ Microsoft DirectX SDK（2010年6月）\ Lib \ x86 \ dxguid”。 lib“（在我的情况下）是唯一的工作。
对我来说问题是一个错误的include目录。 我不知道为什么这会导致看似丢失的lib的错误，因为include目录只包含头文件。 而库目录有正确的path集。
也许你有硬件问题。
我在旧系统（AMD 1800 MHz CPU，1GB RAM，Windows 7 Ultimate）上遇到了同样的问题，直到我将2个512 MB RAM更改为2个1 GB RAM 。 自那以后没有任何问题。 其他（轻微）问题也消失了。 猜测这两个512 MB模块并不是那么相似，因为2个512 MB + 1GB或1个512 MB + 2个1GB的内存不能正常工作。
您也可以通过在DOS“8.3”格式中指定库path来修复path中的空间问题。
要获得8.3表单，请执行（在命令行）：
DIR /AD /X
recursion地通过目录的每个级别。
我有同样的问题。 通过定义一个包含所有链接器对象的macrosOBJECTS来解决它，例如：
OBJECTS = target.exe kernel32.lib mylib.lib (etc)
然后在链接器的命令行中指定$(OBJECTS) 。
我不使用Visual Studio ，只是nmake和.MAK文件
我在project_dir级别创build了一个bin目录，然后在bin文件夹中创build了一个release/debug目录，这为我解决了这个问题。
