Visual Studio: LINK : fatal error LNK1181: cannot open input file

Viewed 252837

I've been encountering a strange bug in Visual Studio 2010 for some time now.

I have a solution consisting of a project which compiles to a static library, and another project which is really simple but depends on this library.

Sometimes, in the last days extremely frequent, after Rebuilding the Solution or just compiling it with 1-3 changed source files, I get the following error:

2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib'
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

Where compiling thelibrary.lib was a success without any errors or warnings.

I have tried cleaning the solution, but that doesn't always work.

  • What is wrong here?
19 Answers

I don't know why, but changing the Linker->Input->Additional Dependencies reference from "dxguid.lib" to "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86\dxguid.lib" (in my case) was the only thing that worked.

I had the same problem. Solved it by defining a macro OBJECTS that contains all the linker objects e.g.:

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

And then specifying $(OBJECTS) on the linker's command line.

I don't use Visual Studio though, just nmake and a .MAK file

I had the same error when running lib.exe from cmd on Windows with a long argument list. apparently cmd.exe has max line length of about 8K characters, which resulted that the filenames at the end of this threshold got changed, thus resulting in bad filename error. my solution was to trim the line. I removed all paths from filenames and added single path using /LIBPATH option. for example:

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

I found a different solution for this...

Actually, I missed comma separator between two library paths. After adding common it worked for me.

Go to: Project properties -> Linker -> General -> Link Library Dependencies At this path make sure the path of the library is correct.

Previous Code (With Bug - because I forgot to separate two lib paths with comma):

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

Code after fix (Just separate libraries with comma):

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

Hope this will help you.

In my case I had the library installed using NuGet package (cpprestsdk) AND I falsely added the lib to the Additional Dependancies in the Linker settings. It turns out, the package does it all for you.

The linker then tried to find the library in the library path and of course could not find it.

After removing the library from the Additional Dependencies everything compiled and linked fine.

Not quite the answer to OP's question as I am using CMake with Visual Studio as a generator but I personally also just encountered the same issue (I am using Visual Studio toolchain, but not the IDE to build stuff).

My fix was target linking the directory of the directory of the libraries (I had a few) before target linking the library.

//Works
target_link_directories(MyExe PRIVATE /out/of/scope/path/to/lib)
foreach(X IN LISTS LIBSLISTNAMES)
    target_link_libraries(MyExe ${X})
endforeach()

//Throws cannot open cannot open input file error
 foreach(X IN LISTS LIBSLISTNAMES)
    target_link_libraries(MyExe /out/of/scope/path/to/lib/${X})
endforeach()

Not sure what is happening under the hood, but maybe VS IDE has equivalent setting somewhere?

I've also experienced this problem. For me the dependencies were properly set, but one of the projects in my solution wasn't selected for building in the configuration (VS 2022 pro).

I eventually figured out thanks to output in Build -> Clean Solution that mentioned one of the project in dependency chain being disabled. Interesingly enough, when trying to build the disabled project it wouldd not properly build its dependencies.

Related