[ACCEPTED]-C++: LINK : debug\XXXXX.exe not found or not built by the last incremental link; performing full link-incremental-linking

Accepted answer
Score: 13

Old question, but just in case for someone 12 it is still an issue (and it is..).

Incremental 11 link is incompatible with generating manifest 10 file (Proj opts > Linker > Manifest 9 File > Generate Manifest: Yes). Indeed, generating 8 manifest modifies exe/dll so linker has 7 to do full linkage.

There are some workarounds, for 6 more details: http://chadaustin.me/2009/05/incremental-linking-and-embedded-manifests/

Temporary (and easiest/fastest) solution 5 is to disable manifest generation during 4 development and enable it again in the release 3 stage. Although this disables XP/Vista-style 2 gui for the app (controls look like in "classic 1 mode").

Score: 6

So it turns out that the problem fixes it 4 self if I add /INCREMENTAL to the linker command line. This 3 in spite the fact that the default behavior 2 according to the docs is to enable incremental 1 linking.

Strange.

Score: 4

Really shooting in the dark but,...

Do you 21 move the XXXXX.exe from where it is built 20 to somewhere else? The whole point of an 19 incremental link is to change an existing 18 exe. If there is none, it will be difficult...

Another 17 possible reason is that the file was changed 16 after the build (probably by another tool)...

All 15 the reasons are listed in the help item for /INCREMENTAL:

Additionally, LINK 14 performs a full link if any of the following situations 13 occur:

The incremental status (.ilk) file 12 is missing. (LINK creates a new .ilk file in 11 preparation for subsequent incremental 10 linking.)

There is no write permission for 9 the .ilk file. (LINK ignores the .ilk 8 file and links nonincrementally.)

The .exe 7 or .dll output file is missing.

The timestamp 6 of the .ilk, .exe, or .dll is changed.

A 5 LINK option is changed. Most LINK options, when 4 changed between builds, cause a full link.

An 3 object (.obj) file is added or omitted.

An 2 object that was compiled with the /Yu 1 /Z7 option is changed.

Score: 3
  1. Download procmon from Microsoft.
  2. Run it, set up a filter so that you are looking for accesses to the path that contains your .exe name.
  3. Do a link.
  4. See what trouble it's having -- does it find it, does it log an error on opening it. Procmon will log every single file open, read, close, etc. If it gets an error, it will log it.
  5. Also make sure it can find the .ilk file -- I think it needs that as well.

0

Score: 1

(ALso in the dark) One possible reason is 3 that you use a project-wide header referencing 2 the __DATE__ macro. But in that case, you'd see 1 a full recompile as well (do you?)

Score: 1

In my case, I have got this error yesterday.

VS 3 set code generation > runtime Library to Multi-threaded Debug DLL (/MDd) instead of Multi-threaded Debug (/MTd).

If i recreate new project 2 this bad settings happens again. I manually 1 switch to /Mtd, then no error happens.

More Related questions