Visual Studio：リンク：致命的なエラーLNK1181：入力ファイルを開けません
しばらくの間、Visual Studio 2010で奇妙なバグに遭遇しました。
静的ライブラリにコンパイルするプロジェクトと、本当にシンプルですがこのライブラリに依存する別のプロジェクトで構成されるソリューションがあります。
ソリューションを再構築するか、変更したソースファイルを1〜3個だけコンパイルした後、最後の数日間に非常に頻繁に、次のエラーが発生することがあります。
2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib'
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
thelibrary.libのコンパイルは、エラーや警告なしで成功しました。
ソリューションのクリーニングを試みましたが、常にうまくいくとは限りません。
- ここで何が間違っていますか？
一般的なリンカーの追加ライブラリディレクトリで、リンカー、入力に含めた.dllまたは.libにディレクトリを追加します。これをVC++ディレクトリ、ライブラリディレクトリに配置すると機能しません。
に行く：
Project properties -> Linker -> General -> Link Library Dependencies set No.
ここで起こっているのは1つだけです。プロジェクトでlibrary.libに適切に依存関係を設定していません。つまり、library.libが間違った順序でビルドされています（または、CPUビルド構成が1つ以上ある場合、エラーのランダム性も説明できます）。 （プロジェクトの依存関係は、メニュー->プロジェクト->プロジェクトの依存関係で変更できます）
最近、同じエラーが発生しました。いくつかの掘りがこれをもたらしました： http://support.Microsoft.com/kb/815645
基本的に、.libのパスにスペースがある場合、それは悪いことです。それがあなたのために何が起こっているのかわからないが、合理的に可能だと思われる。
修正方法は、1）lib参照を「引用符」で囲むか、2）libのパスをライブラリディレクトリに追加します（構成プロパティ>> VC++ディレクトリ）。
VS 2010とVS 2012の両方で同じ問題が発生しました。私のシステムでは、最初の静的ライブラリが構築され、メインプロジェクトの構築が開始されるとすぐに削除されました。
問題は、いくつかのプロジェクトの共通の中間フォルダーです。各プロジェクトに個別の中間フォルダーを割り当てるだけです。
詳細はこちら こちら
私は次のように解決しました：
[表示]-> [プロパティページ]-> [構成プロパティ]-> [リンカ]-> [入力]に移動します。
追加の依存関係の下にthelibrary.libを追加します。引用符を使用しないでください。
プロジェクト自体の一部であるLINK1181ファイルで.OBJエラーが発生していたという点で同様の問題がありました（プロジェクト全体で2つの.cxxファイルしかありませんでした）。
最初に、Visual Studioで.EXEを生成するようにプロジェクトをセットアップしてから、Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Typeで.EXEを.DLLに変更しました。どういうわけかVisual Studio 2008が混乱しているのではないかと疑って、最初から.DLLモードを使用してソリューション全体をゼロから再作成しました。その後、問題はなくなりました。 .vcprojおよびその他の関連ファイルを手動で選択した場合、ゼロから開始せずに問題を修正する方法を見つけることができると思います（ただし、私のプログラムは2つの.cppファイルで構成されていたため、最初からやりやすくなりました）。
理由はわかりませんが、リンカー->入力->追加の依存関係の参照を「dxguid.lib」から「C：\ Program Files（x86）\ Microsoft DirectX SDK（2010年6月）\ Lib\x86\dxguid」に変更します。 lib "（私の場合）が唯一機能した。
私は同じ問題につまずいています。私にとっては、同じ名前のプロジェクトが2つあり、一方が他方に依存していることが原因のようです。
たとえば、Foo.libを生成するFooという名前のプロジェクトが1つあります。次に、Foo.exeとFoo.lib内のリンクを生成するFooという名前の別のプロジェクトがあります。
プロセスモニターでファイルアクティビティを監視しました。起こっているように見えるのは、Foo（lib）が最初にビルドされることです。これは、Foo（exe）がFoo（lib）に依存しているとマークされているため適切です。これはすべて問題なく、正常にビルドされ、出力ディレクトリ（$（OutDir）$（TargetName）$（TargetExt））に配置されます。次に、Foo（exe）がトリガーされて再構築されます。さて、再構築はクリーンであり、ビルドがそれに続きます。 Foo.exeの「クリーン」ステージが出力ディレクトリからFoo.libを削除しているようです。これは、後続の「ビルド」が機能する理由も説明します-出力ファイルを削除しません。
VSのバグだと思います。
残念ながら、リビルドが関係しているため、問題の解決策がありません。回避策は、Cleanを手動で発行してからBuildすることです。
私にとって、問題は間違ったincludeディレクトリでした。インクルードディレクトリにはヘッダーファイルしか含まれていないため、これが原因でlibが見つからないというエラーが発生した理由はわかりません。また、ライブラリディレクトリには正しいパスが設定されていました。
長い引数リストを使用してWindowsでcmdからlib.exeを実行すると、同じエラーが発生しました。明らかにcmd.exeの最大行長は約8K文字であるため、このしきい値の最後のファイル名が変更され、ファイル名エラーが発生しました。私の解決策は、ラインをトリミングすることでした。ファイル名からすべてのパスを削除し、/ LIBPATHオプションを使用して単一のパスを追加しました。例えば：
/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj
ハードウェアに問題がある可能性があります。
2x 512 MB RAMを2xに変更するまで、古いシステム（AMD 1800 MHz CPU、1GB RAM、Windows 7 Ultimate）で同じ問題が発生しました。 1GB RAM。それ以来、問題はありませんでした。また、他の（マイナーな）問題もなくなりました。 2x 512 MB + 1GBまたは1x 512 MB + 2x 1GBが適切に機能しなかったため、これら2つの512 MBモジュールはあまり好きではなかったと思います。
私の場合、NuGetパッケージ（cpprestsdk）を使用してライブラリをインストールし、リンカー設定の追加の依存関係に誤ってライブラリを追加しました。結局のところ、パッケージはあなたのためにそれをすべて行います。
その後、リンカはライブラリパスでライブラリを見つけようとしましたが、もちろんそれを見つけることができませんでした。
追加の依存関係からライブラリを削除した後、すべてがコンパイルおよびリンクされます。
これに対して別の解決策を見つけました...
実際、2つのライブラリパスの間のコンマ区切りがありませんでした。共通を追加した後、それは私のために働いた。
Project properties -> Linker -> General -> Link Library Dependenciesに移動します。このパスで、ライブラリのパスが正しいことを確認します。
前のコード（バグあり-2つのlibパスをコンマで区切るのを忘れたため）：
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
修正後のコード（ライブラリをカンマで区切るだけ）：
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**;..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
これがお役に立てば幸いです。
同じ問題がありました。すべてのリンカーオブジェクトを含むマクロOBJECTSを定義することで解決しました。例：
OBJECTS = target.exe kernel32.lib mylib.lib (etc)
そして、リンカのコマンドラインで$(OBJECTS)を指定します。
Visual Studioは使用せず、nmakeと.MAKファイルのみ
また、DOSの「8.3」形式でライブラリパスを指定することで、パス内のスペースの問題を修正することもできます。
8.3形式を取得するには、次を実行します（コマンドラインで）：
DIR /AD /X
ディレクトリのすべてのレベルを再帰的に繰り返します。