Visual Studio: LINK: фатальная ошибка 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 имела успех без каких-либо ошибок или предупреждений.

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

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

Ответ 1

В Linker, общие, дополнительные каталоги библиотек, добавьте каталог в DLL или .lib, которые вы включили в Linker, Input. Это не работает, если вы поместите это в каталоги VС++, каталоги библиотек.

Ответ 2

Перейдите к:

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

Перейдите в View- > Страницы свойств → Свойства конфигурации → Коннектор → Вход

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

Ответ 8

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

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

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

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

Возможно, у вас есть проблемы с оборудованием.

У меня была такая же проблема на моей старой системе (процессор AMD 1800 МГц, 1 ГБ оперативной памяти, Windows 7 Ultimate), пока я не изменил 2x 512 МБ ОЗУ на 2x 1 ГБ ОЗУ. С тех пор не было никаких проблем. Также исчезли другие (второстепенные) проблемы. Угадайте, что эти два модуля объемом 512 МБ не очень понравились друг другу, потому что 2x 512 МБ + 1 ГБ или 1x 512 МБ + 2x 1 ГБ тоже не работали.

Ответ 12

Вы также можете исправить проблему пробела в пути, указав путь библиотеки в формате DOS "8.3".

Чтобы получить форму 8.3, выполните (в командной строке):

DIR /AD /X

рекурсивно через каждый уровень каталогов.

Ответ 13

У меня была та же проблема. Решил его, указав макрос OBJECTS, содержащий все объекты компоновщика, например:

OBJECTS = target.exe kernel32.lib mylib.lib (etc)

И затем укажите $(OBJECTS) в командной строке компоновщика.

Я не использую Visual Studio, хотя, просто nmake и .MAK файл

Ответ 14

У меня была такая же ошибка при запуске lib.exe из cmd в Windows с длинным списком аргументов. очевидно, cmd.exe имеет максимальную длину строки около 8 КБ символов, в результате чего имена файлов в конце этого порога были изменены, что привело к ошибочной ошибке в имени файла. Мое решение было урезать линию. Я удалил все пути из имен файлов и добавил один путь, используя параметр /LIBPATH. например:

/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj

Ответ 15

Я нашел другое решение для этого...

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

Перейдите в: Project properties → Linker → General → Link Library Dependencies По этому пути убедитесь, что путь к библиотеке правильный.

Предыдущий код (с ошибкой - потому что я забыл разделить два пути lib запятой):

<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>

Код после исправления (просто разделяйте библиотеки запятыми):

<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**;..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>

Надеюсь, что это поможет вам.

Ответ 16

В моем случае у меня была установлена библиотека с использованием пакета NuGet (cpprestsdk), и я ошибочно добавил библиотеку к дополнительным зависимостям в настройках компоновщика. Оказывается, пакет делает все это за вас.

Затем компоновщик попытался найти библиотеку в пути к библиотеке и, конечно, не смог ее найти.

После удаления библиотеки из дополнительных зависимостей все скомпилировалось и связывалось нормально.

Ответ 17

Я создал каталог bin на уровне project_dir, а затем создал каталог release/debug внутри папки bin, который решил проблему для меня.