Visual C/C++ linker sometimes fails to update an executable with updated object code - by garethrees

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 3104624 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 9/27/2016 9:50:13 AM
Access Restriction Public


When cl.exe is used to compile and incrementally link a new object file into an executable, sometimes it fails to update the executable with updated object code. See the detailed reproduction steps below. I have reproduced this with Visual C/C++ 2010 and with Visual C/C++ 2015 (Community Edition).
Sign in to post a comment.
Posted by garethrees on 10/6/2016 at 11:15 AM
I'm very pleased to hear it and I look forward to trying the new release. Thank you!
Posted by YongKang [MSFT] on 10/6/2016 at 10:42 AM
We have fixed this issue and made the linker more robust on determining whether an OBJ file has actually changed since last linking. The fix will be in our upcoming major VS release. Thanks for taking the time to report this issue to us!
Posted by garethrees on 10/2/2016 at 2:28 PM
Obviously I could insert a "timeout" between compilations in my test script, but I have many hundreds of test cases, and adding hundreds of seconds to the run time for the test suite would not be acceptable.

Instead I have a different workaround. I have observed that if the new object file is a different size from the old object file, then the linker always successfully updates it in the executable. (It seems that the linker consults the object file's name, size, and modification time in seconds.) So I can artificially adjust the test cases so that each compilation results in an object file with a different length.

Nonetheless I thought that you might interested in making the linker more reliable in this respect. Disk caches are fast enough these days that the linker could make use of more information about the object file to determine whether to update it, without unduly penalizing overall link time.
Posted by garethrees on 10/2/2016 at 2:22 PM
YongKang: Thanks for your response. I had the idea that the linker might be using a low-resolution timestamp (e.g. 1 second resolution) to determine whether or not to update the executable with the object code. So I ran the following test (using timeout 1 to wait until the next second):

cl /nologo /Foo /Fee a.c /link /debug >nul & e & timeout 1 >nul & cl /nologo /Foo /Fee b.c /link /debug >nul & e

In my tests, this succeeded 100% of the time (the output was always "a" followed by "b" as expected).
Posted by YongKang [MSFT] on 9/28/2016 at 11:13 AM
Our linker internally will compare the timestamp of the two OBJs before and after the first linking is done. I suspect what happened is that the the compiling and linking finished too soon and the two OBJs end up having same timestamp in their headers, which makes the linker think nothing has changed. Could you double check on this? This can be easily worked around by adding a "sleep <a-few-seconds>" in your test script.
Posted by Microsoft on 9/27/2016 at 6:45 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If you require immediate assistance with this issue, please contact product support at