Closed jasonwhite closed 8 years ago
My hunch was right. It turns out that the .ilk
file stores the PDB signature and the linker is comparing it with the one in the EXE/DLL/PDB and failing because they don't match. Doing a search and replace fixes the problem. Unfortunately, the Microsoft Linker Database format is not documented anywhere on the internet (that I could find). An effective solution, albeit hacky, is to simply map the .ilk
file into memory, search for the old PDB signature, and replace it with the new one.
Patching the .ilk
file solves the failure, but incremental linking still does not run. For now, we will just patch the PDB signature in the .ilk
file and ignore that incremental linking is broken. Fixing this will likely be a big job as making the output deterministic will be difficult or impossible when linking incrementally. The primary purpose of this tool is to be run on full rebuilds of release builds (where /INCREMENTAL
is not specified).
I don't want to open, but just to cofirm - the issue would be only if the PDB gets reused in the compilation, e.g. if I build my things in a "intermediate/" folder, where there are .pdb, .ilk, etc. files, and then I deploy to a "bin/" folder and "ducible" in there - it should work, right?
Yes, it should just work. If not, submit a separate issue and I'll get it fixed.
Edit: By "work" I mean the tool won't fail, but it might not make the output deterministic. If link
is run with /INCREMENTAL
, the output cannot be made deterministic.
When building incrementally, the linker fails with the error
LNK1209: program database 'foo.pdb' differs from previous link; relink or rebuild
.This could be caused by a number of reasons, one being that the resulting PDB is simply not valid. The linker may also keep information about the state of the PDB separately (maybe in the
.ilk
file). This needs to be researched more.