Ответ 1
В Linker, общие, дополнительные каталоги библиотек, добавьте каталог в DLL или .lib, которые вы включили в Linker, Input. Это не работает, если вы поместите это в каталоги VС++, каталоги библиотек.
Я уже некоторое время встречаю странную ошибку в 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. Это не работает, если вы поместите это в каталоги VС++, каталоги библиотек.
Перейдите к:
Project properties -> Linker -> General -> Link Library Dependencies set No.
Я вижу только 1 вещи, происходящие здесь: Вы не установили должным образом зависимости от thelibrary.lib в своем проекте, что означает, что thelibrary.lib построен в неправильном порядке (или в то же время, если у вас более 1 конфигурация сборки CPU, что также может объяснить случайность ошибки), (Вы можете изменить зависимости проекта в: Menu- > Project- > Project Dependencies)
Недавно я попал в ту же ошибку. Некоторое копание вызвало это: http://support.microsoft.com/kb/815645
В принципе, если у вас есть пробелы на пути .lib, это плохо. Не знаю, что с тобой происходит, но кажется разумным.
Исправление: либо 1) поместить ссылку на lib в "кавычки", либо 2) добавить путь lib к вашим библиотечным каталогам (Свойства конфигурации → Каталоги VС++).
У меня была такая же проблема как в VS 2010, так и в VS 2012. В моей системе была создана первая статическая библиотека, а затем сразу же удалена при запуске основного проекта.
Проблема заключается в общей промежуточной папке для нескольких проектов. Просто назначьте отдельную промежуточную папку для каждого проекта.
Подробнее об этом здесь
У меня была аналогичная проблема, так как я получал ошибки LINK1181
в файле .OBJ
, который был частью самого проекта (и во всем проекте было всего 2 файла .cxx).
Сначала я установил проект для создания .EXE
в Visual Studio, а затем в
Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Type
, я изменил .EXE на .DLL. Подозревая, что Visual Studio 2008 каким-то образом запуталась, я с самого начала воссоздал все решение с нуля с использованием режима .DLL. После этого проблема исчезла. Я предполагаю, что если вы вручную проведете свой путь через .vcproj и другие связанные файлы, вы сможете выяснить, как исправить ситуацию, не начиная с нуля (но моя программа состояла из двух файлов .cpp, поэтому было легче начать все заново).
Я решил это со следующим:
Перейдите в View- > Страницы свойств → Свойства конфигурации → Коннектор → Вход
В дополнительных зависимостях добавьте thelibrary.lib. Не используйте никаких цитат.
Я сталкиваюсь с тем же вопросом. Для меня это, по-видимому, вызвано наличием двух проектов с тем же именем, один из которых зависит от другого.
Например, у меня есть один проект с именем 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.
Я не знаю почему, но изменив ссылку 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), пока я не изменил 2x 512 МБ ОЗУ на 2x 1 ГБ ОЗУ. С тех пор не было никаких проблем. Также исчезли другие (второстепенные) проблемы. Угадайте, что эти два модуля объемом 512 МБ не очень понравились друг другу, потому что 2x 512 МБ + 1 ГБ или 1x 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 имеет максимальную длину строки около 8 КБ символов, в результате чего имена файлов в конце этого порога были изменены, что привело к ошибочной ошибке в имени файла. Мое решение было урезать линию. Я удалил все пути из имен файлов и добавил один путь, используя параметр /LIBPATH. например:
/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj
Я нашел другое решение для этого...
На самом деле, я пропустил разделитель запятой между двумя путями библиотеки. После добавления общего у меня это сработало.
Перейдите в: 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>
Надеюсь, что это поможет вам.
В моем случае у меня была установлена библиотека с использованием пакета NuGet (cpprestsdk), и я ошибочно добавил библиотеку к дополнительным зависимостям в настройках компоновщика. Оказывается, пакет делает все это за вас.
Затем компоновщик попытался найти библиотеку в пути к библиотеке и, конечно, не смог ее найти.
После удаления библиотеки из дополнительных зависимостей все скомпилировалось и связывалось нормально.
Я создал каталог bin
на уровне project_dir, а затем создал каталог release/debug
внутри папки bin
, который решил проблему для меня.