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 + 1GB1个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目录,这为我解决了这个问题。