Visual Studio: ССЫЛКА: фатальная ошибка LNK1181: не удается открыть входной файл

Question

Я уже некоторое время сталкиваюсь со странной ошибкой в ​​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 прошла успешно без каких-либо ошибок или предупреждений.

Я пытался очистить решение, но это не всегда работает.

• Что здесь не так?

Answer 1

В Linker, общих каталогах дополнительных библиотек, добавьте каталог в .dll или .libs, которые вы включили в Linker, Input.Это не работает, если вы поместите это в каталоги VC ++, каталоги библиотек.

Answer 2

Перейти к:

Project properties -> Linker -> General -> Link Library Dependencies set No.

Answer 3

Я вижу, что здесь происходит только 1 вещь: вы неправильно установили зависимости для thelibrary.lib в своем проекте, что означает, что thelibrary.lib построен в неправильном порядке (или в то же время, если у вас более 1 процессораКонфигурация сборки, которая также может объяснить случайность ошибки).(Вы можете изменить зависимости проекта в: Меню-> Проект-> Зависимости проекта)

Answer 4

Я недавно столкнулся с той же ошибкой.Некоторые раскопки подняли это: http://support.microsoft.com/kb/815645

В принципе, если у вас есть пробелы на пути к .lib, это плохо.Не знаю, происходит ли это для вас, но это кажется разумно возможным.

Исправление: 1) поместите ссылку на lib в "кавычки", или 2) добавьте путь к lib в ваши каталоги библиотек (конфигурацияСвойства >> Каталоги VC ++).

Answer 5

У меня была одна и та же проблема как в VS 2010, так и в VS 2012. В моей системе была собрана первая статическая библиотека, а затем сразу же была удалена, когда основной проект начал собираться.

Проблема в общей промежуточной папкедля нескольких проектов.Просто назначьте отдельную промежуточную папку для каждого проекта.

Подробнее об этом здесь

Answer 6

Я решил это следующим образом:

Перейдите в View-> Страницы свойств -> Свойства конфигурации -> Linker -> Input

Под дополнительными зависимостями добавьте thelibrary.lib.Не используйте цитаты.

Answer 7

У меня была похожая проблема в том, что я получал LINK1181 ошибки в файле .OBJ, который был частью самого проекта (и во всем проекте было только 2 файла .cxx).

Изначально я настроил проект для генерации .EXE в Visual Studio, а затем в Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Type я изменил .EXE на .DLL.Подозревая, что Visual Studio 2008 каким-то образом запутался, я с самого начала воссоздал все решение с нуля, используя режим .DLL.Проблема ушла после этого.Я полагаю, если вы вручную выберете путь к .vcproj и другим связанным файлам, вы сможете выяснить, как все исправить, не начиная с нуля (но моя программа состояла из двух файлов .cpp, поэтому было проще начать все сначала).

Answer 8

Для меня проблема была в неправильном каталоге include. Я понятия не имею, почему это вызвало ошибку с отсутствующей на первый взгляд библиотекой, поскольку каталог include содержит только файлы заголовков. И в каталоге библиотеки был указан правильный путь.

Answer 9

Я не знаю почему, но изменив ссылку Linker-> Input-> Additional Dependencies с "dxguid.lib" на "C: \ Program Files (x86) \ Microsoft DirectX SDK (июнь 2010 г.) \ Lib \ x86\ dxguid.lib "(в моем случае) - единственное, что сработало.

Answer 10

Я сталкиваюсь с той же проблемой. Для меня это, кажется, вызвано наличием двух проектов с одинаковыми именами, один из которых зависит от другого.

Например, у меня есть один проект с именем Foo, который производит Foo.lib. Затем у меня есть другой проект, который также называется Foo, который производит Foo.exe и ссылки в Foo.lib.

Я наблюдал за активностью файла с Process Monitor. Кажется, происходит то, что Foo (lib) создается первым - это правильно, потому что Foo (exe) помечен как зависящий от Foo (lib). Это все нормально и успешно собирается, и помещается в выходной каталог - $ (OutDir) $ (TargetName) $ (TargetExt). Затем Foo (exe) запускается для восстановления. Ну, перестройка - это чистая, за которой следует сборка. Кажется, что «чистым» этапом Foo.exe является удаление Foo.lib из выходного каталога. Это также объясняет, почему работает следующая сборка, которая не удаляет выходные файлы.

Ошибка в VS, я думаю.

К сожалению, у меня нет решения проблемы, так как оно связано с перестройкой. Обходной путь - вручную выполнить команду «Очистить», а затем «Построить».