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

A

7

17

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?

Antares answered 12/10, 2009 at 14:44 Comment(0)

A

6

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.

Antares answered 13/10, 2009 at 19:34 Comment(1)

This did it for me. Big help! – Satterlee 24/9, 2010 at 18:8

A

13

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").

Ap answered 17/4, 2010 at 18:1 Comment(0)

A

6

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.

Antares answered 13/10, 2009 at 19:34 Comment(1)

This did it for me. Big help! – Satterlee 24/9, 2010 at 18:8

P

4

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.

Paraesthesia answered 13/10, 2009 at 9:42 Comment(2)

Nope.. nothing touches the exe after linking. – Antares 13/10, 2009 at 12:16

How about things like virus scanners, search indexers, backup software? Is something touching all new files on your system? – Veritable 13/10, 2009 at 20:40

V

3

Download procmon from Microsoft.
Run it, set up a filter so that you are looking for accesses to the path that contains your .exe name.
Do a link.
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.
Also make sure it can find the .ilk file -- I think it needs that as well.

Veritable answered 13/10, 2009 at 15:21 Comment(3)

Here's the log: shiny.co.il/shooshx/k/Kawaiiexe.PML I can't really see anything extremely wrong. can you? – Antares 13/10, 2009 at 16:24

Posting a text file would help those that do not have procmon installed. – Paraesthesia 13/10, 2009 at 16:30

I don't see anything -- it's clearly finding the file. For some reason, it's rejecting it and probably falling back to a catchall error message. – Veritable 13/10, 2009 at 20:35

H

1

(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?)

Halpin answered 13/10, 2009 at 9:58 Comment(1)

there's never a full recompile and I'm not referencing DATE anywhere – Antares 13/10, 2009 at 12:16

H

1

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.

Haldas answered 4/10, 2013 at 18:38 Comment(0)

T

0

I was running a batch script and having it delete the exe before compile, so I could then check for the compiled exe after compilation before running the exe:

pushd build
del win32_handmade.exe
cl -FC -Zi ..\code\win32_handmade.cpp user32.lib Gdi32.lib
IF EXIST "win32_handmade.exe" call "../build/win32_handmade.exe"

Of course, using @REM to comment out the line that delete the exe would work, but that's not even really a solution:

@REM del win32_handmade.exe

One way I found to get around the error message: when you delete the .exe, you can avoid the warning message by also deleting any .ilk, which contains the linking data:

del win32_handmade.exe
del win32_handmade.ilk

So far, the best solution I've found is to disable incremental linking. You can do this by adding /link /INCREMENTAL:NO to the end of your cl command, like so:

cl -FC -Zi ..\code\win32_handmade.cpp user32.lib Gdi32.lib /link /INCREMENTAL:NO

Than answered 29/5, 2023 at 18:54 Comment(0)

Recommended topics

Hot tags