Odd. Maybe ...

The .ilk file isn't needed as a dependency. The linker should generate it if needed. I tested this with base on a component build. If I build base, delete base.ilk, and then ask ninja to rebuild base it says there is nothing to be done. If I manually relink then it happily does so - no complaints about the missing base.ilk.

Searching on stack overflow suggests a couple of causes: the .ilk file could be corrupt (I'm skeptical) or there could be multiple processes trying to open the .ilk file, perhaps because a previous build did not stop or because multiple files are writing to tracing.ilk.

My guess is that tracing.service should be writing to tracing.service.ilk. And, the /OUT name for tracing.service should be tracing.service.DLL. Probably the .ilk name generation logic is confusing ".service" for the file extension, creating a tracing.ilk file, and this conflicts with a separate link step.

I'll investigate further.

Repro steps, for a component build:

> ninja tracing.dll tracing.service
> del tracing.dll & del tracing.ilk & del tracing.service
> ninja tracing.dll tracing.service
[2 processes, 1/2 @ 7.5/s : 0.133s ] LINK tracing.service tracing.service.pdb
FAILED: tracing.service tracing.service.pdb
C:/src/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x86 False link.exe /nologo /OUT:./tracing.service /PDB:./tracing.service.pdb @./tracing.service.rsp
LINK : fatal error LNK1104: cannot open file './tracing.ilk'
[1 processes, 2/2 @ 6.7/s : 0.299s ] LINK(DLL) tracing.dll tracing.dll.lib tracing.dll.pdb
ninja: build stopped: subcommand failed.

So, it's a simple race condition caused by the fact that tracing.dll and tracing.service both generate tracing.ilk. I'm not aware of a way to change the incremental linking name. A quick-hack fix would be to disable incremental linking for one of the targets (it isn't important for small targets like these) but that leaves the risk intact.

Is it practical to change the naming convention for services, perhaps to *.service.dll? That would avoid conflicts (current and future) between the .ilk files for services and components.

This isn't *required*, but it would ensure that we don't repeat this bug.

Just in case I'm preparing a CL to disable incremental linking for tracing.dll.

You mean *.service.exe? Sure, we could do that. I really like the
uniformity of having the same binary names everywhere, but it's not the end
of the world if we have to change it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f5230da72019de8ae225833e75e94519cad77232

commit f5230da72019de8ae225833e75e94519cad77232
Author: rockot <rockot@chromium.org>
Date: Thu Dec 15 22:20:14 2016

Use .service.exe extension for service binaries on Windows

This is a simple solution to avoid conflicting ILK filenames
generated by the linker, which apparently just strips the
output file extension.

BUG= 673521 
TBR=ben@chromium.org

Review-Url: https://codereview.chromium.org/2578183003
Cr-Commit-Position: refs/heads/master@{#438935}

[modify] https://crrev.com/f5230da72019de8ae225833e75e94519cad77232/services/catalog/reader.cc
[modify] https://crrev.com/f5230da72019de8ae225833e75e94519cad77232/services/service_manager/public/cpp/service.gni
[modify] https://crrev.com/f5230da72019de8ae225833e75e94519cad77232/services/service_manager/runner/host/child_process_host_unittest.cc

I can confirm that a local Windows build of //services/tracing does indeed now produce a tracing.service.ilk, so it seems like this should effectively resolve the conflict.

One additional thought: is there some way we can modify GN executable and shared_library rules so that on Windows the .ilk file becomes a known output? Then we could get warnings about multiple targets producing the same file, couldn't we?

I'm sure it's possible, but it would have to track which targets had incremental linking enabled. I don't know how easy that is.