Using visual studio 2008 SP1,
This line:
LINK : debug\XXXXX.exe not found or not built by the last incremental link; performing full link
appears every single time I compile the project, no matter how small a change I make.
What could be the reasons for that?
Old question, but just in case for someone it is still an issue (and it is..).
Incremental link is incompatible with generating manifest file (Proj opts > Linker > Manifest File > Generate Manifest: Yes). Indeed, generating manifest modifies exe/dll so linker has to do full linkage.
There are some workarounds, for more details:
http://chadaustin.me/2009/05/incremental-linking-and-embedded-manifests/
Temporary (and easiest/fastest) solution is to disable manifest generation during development and enable it again in the release stage. Although this disables XP/Vista-style gui for the app (controls look like in "classic mode").
So it turns out that the problem fixes it self if I add /INCREMENTAL
to the linker command line. This in spite the fact that the default behavior according to the docs is to enable incremental linking.
Strange.
Really shooting in the dark but,...
Do you move the XXXXX.exe from where it is built to somewhere else? The whole point of an incremental link is to change an existing exe. If there is none, it will be difficult...
Another possible reason is that the file was changed after the build (probably by another tool)...
All the reasons are listed in the help item for /INCREMENTAL:
Additionally, LINK performs a full
link if any of the following
situations occur:
The incremental status (.ilk) file is
missing. (LINK creates a new .ilk file
in preparation for subsequent
incremental linking.)
There is no write permission for the
.ilk file. (LINK ignores the .ilk file
and links nonincrementally.)
The .exe or .dll output file is
missing.
The timestamp of the .ilk, .exe, or
.dll is changed.
A LINK option is changed. Most LINK
options, when changed between builds,
cause a full link.
An object (.obj) file is added or
omitted.
An object that was compiled with the
/Yu /Z7 option is changed.
(ALso in the dark) One possible reason is that you use a project-wide header referencing the __DATE__
macro. But in that case, you'd see a full recompile as well (do you?)
In my case, I have got this error yesterday.
VS set code generation > runtime Library
to Multi-threaded Debug DLL (/MDd)
instead of Multi-threaded Debug (/MTd)
.
If i recreate new project this bad settings happens again. I manually switch to /Mtd
, then no error happens.