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 была успешной без каких-либо ошибок или предупреждений.

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

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

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

Идти к:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 DIR /AD /X 

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

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

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

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

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

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

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

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