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 або .libs, які ви включили до Linker, Input. Це не спрацює, якщо ви поміщаєте це у VC ++ Каталоги, Бібліотечні каталоги.

Йти до:

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

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

Нещодавно я потрапив у ту ж помилку. Деякі копання підняли це: http://support.microsoft.com/kb/815645

В основному, якщо у вас є пробіли на шляху до .lib, це погано. Не знаю, чи це саме те, що відбувається з вами, але здається обґрунтовано можливим.

Виправлення полягає в тому, щоб: 1) помістити посилання на lib у "лапки", або 2) додати шлях до бібліотеки до ваших каталогів бібліотеки (Властивості конфігурації >> Каталоги VC ++).

У мене була така сама проблема як у VS 2010, так і в VS 2012. У моїй системі була побудована перша статична бібліотека, а потім її негайно видалено, коли основний проект починав будуватися.

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

Детальніше про це читайте тут

Я вирішив це наступним чином:

Перейдіть до Перегляд-> Сторінки властивостей -> Властивості конфігурації -> Посилання -> Введення

Під додаткові залежності додайте thelibrary.lib. Не використовуйте жодних цитат.

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

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

Я натрапляю на те саме питання. Для мене це, здається, спричинено наявністю 2 проектів з однаковою назвою, один залежно від іншого.

Наприклад, у мене є один проект на ім'я Foo, який створює Foo.lib. Потім у мене є інший проект, який також називається Foo, який виробляє Foo.exe та посилання у Foo.lib.

Я спостерігав за активністю файлів з монітором процесів. Те, що, здається, відбувається, це те, що Foo (lib) будується спочатку - це правильно, оскільки Foo (exe) позначений як залежний від Foo (lib). Це все добре і успішно будується, і розміщується у вихідному каталозі - $ (OutDir) $ (TargetName) $ (TargetExt). Тоді Foo (exe) запускається для відновлення. Що ж, відновлення - це чистота, за якою йде побудова. Здається, що "чистий" етап Foo.exe видаляє Foo.lib з вихідного каталогу. Це також пояснює, чому працює наступна "збірка" - яка не видаляє вихідні файли.

Я думаю, помилка у VS.

На жаль, я не маю рішення проблеми, оскільки вона передбачає відновлення. Обхідним шляхом є вручну видати Clean, а потім побудувати.

Не знаю чому, але змінивши посилання Linker-> Input-> Additional Dependencies з "dxguid.lib" на "C: \ Program Files (x86) \ Microsoft DirectX SDK (червень 2010) \ Lib \ x86 \ dxguid. lib "(у моєму випадку) - це єдине, що спрацювало.

Для мене проблемою був неправильний includeкаталог. Я не уявляю, чому це спричинило помилку з, здавалося б, відсутньою бібліотекою, оскільки каталог include містить лише файли заголовків. І каталог бібліотеки встановив правильний шлях.

Можливо, у вас проблема з апаратним забезпеченням.

У мене була та сама проблема в моїй старій системі (процесор AMD 1800 МГц, 1 Гб оперативної пам'яті, Windows 7 Ultimate), поки я не змінив 2x 512 MB RAM на 2x 1GB RAM . З тих пір у мене не було проблем. Також зникли інші (незначні) проблеми. Думаю, ці два модулі обсягом 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 На цьому шляху переконайтеся, що шлях до бібліотеки правильний.

Попередній код ( із помилкою - тому що я забув відокремити два шляхи до бібліотеки комою):

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

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

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

Сподіваюся, це допоможе вам.

У моєму випадку у мене була встановлена ​​бібліотека за допомогою пакета NuGet (cpprestsdk) І я помилково додав lib до Додаткових залежностей у налаштуваннях Linker. Виявляється, пакет робить все це за вас.

Потім компонувальник спробував знайти бібліотеку на шляху бібліотеки і, звичайно, не зміг її знайти.

Після видалення бібліотеки з Додаткових залежностей все скомпільоване та зв’язане чудово.

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