LINK : fatal error LNK1181: cannot open input file ‘C:\Program.obj’

Now, I know there are some errors in this huge, world-changing article… but, it’s too tedious to deal with right now…

So I decided to walk down to my local Ace Hardware to get some cactus mix, whence I had the bright idea: extract just the section on “fatal error LNK1181: cannot open input file C:\Program.obj” for independent publication, leave the rest for later. (This will help me get specific feedback too, if something incorrect or if someone has another example.)

This isn’t unusual. Taking care of plants helps me relax, making it easier to prioritize my work when I’m overloaded. My goal for this excursion was to repot about a dozen species of succulents, mostly kalanchoe and sedum, which were blown away.

It was horrible.

A huge blast of wind like a giant hand smacked my apartment, from the northeast, right on my bedroom wall. It blasted my girlfriend and I right out of bed and sent my seedling rack careening… a long ride down a short flight of stairs. It was 3am. I remember the fantastic crashing crashing noise, as do the neighbors. It freaked us out!

You can see the results (image up and right) after I swept everything up. This was 2 months ago… and it’s now warm enough, with enough daylight, that I’m ready to repot.

What does this have to do with linker errors?

Well, directly not a lot, but one thing leads to another, and good ideas come from the strangest places. Fiddling around with exotic succulents from Madagascar seems to free up my creative energy so much better than hanging out in a cubical…

… so let’s take a look at LNK1181, which has thoroughly kicked my butt in the past…

1>LINK : fatal error LNK1181: cannot open input file ‘C:\Program.obj’

Here’s three ways to get LNK1181 with the “C:\Program.obj” message:

One way this occurs is due to spaces in the path name in the “input” configuration for libraries. One way to fix it is to put the library path in the directories input section in Linker -> General.
Here is an example taken from a build of Feeling Software’s FCollada library:

Location of FCollada: C:\Program Files (x86)\Feeling Software\FCollada
An convenient environment variable is defined for that path:
FCOLLADADIR=C:\Program Files (x86)\Feeling Software\FCollada

Using $(FCOLLADADIR)\FCollada.lib results in the link error.

Using the quoted form "$(FCOLLADADIR)\FCollada.lib" does not result in a link error. That is, the quotes “” are necessary.
Another way this error can happen is when there is a double path separator. For example:
```
C:\dir0\dir1\\dir2\dir3
```
will confuse VC++. It’s harder to see this in a long list of library includes than it is to fix it.
Yet another trigger is if a path gets newlined. For example,
```
C:\Path\to\my\library
```
turns into
```
C:\Path\to\
my\library
```
This is another one that’s hard to find in a long list of library paths. Hard to guard against too, because both paths are valid, and without more context, the parser can’t know that the second, relative path is supposed part of the first, absolute path.

(This particular problem was a side effect of having qmake translate Qt .profile files into .vcproj files. Considering the size of the project, fixing this manually once in a while was a small price to pay.)

Make sure to read Microsoft’s article 815645 and 839286 on LNK1181 as well. Both of these are pretty good articles, and like the unix man pages, once you figure out the problem, you can’t say the man page didn’t say that.

Did I mention I want feedback? Help me help other programmers:

If there is any inaccuracy in this article, please, leave me a comment and tell me what it is!
If you have a 4th example that results in LNK1181, please leave a comment as well.