We see the following warning during linking: uuid.lib(unknwn_i.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance For some reason the uuid.lib included with the last couple editions of the Windows 10 SDK was compiled with /GL. When the remainder of the local build is not, it forces the linker to do a full link instead of an incremental link, which greatly slows down local builds. The only reference to the problem that I found on Microsoft's website is in the URL field: Since this is an SDK problem and not a MSVC problem, there are no further updates on Microsoft Connect.
Is there anything we can do about it?
I mean, adding /LTCG to the link command line doesn't exactly sound better...
Short of getting an update from Microsoft and documenting a warning on MDN, probably not. But I wanted to make sure that this was on file somewhere.
Can we build and provide our own uuid library?
Possibly given that those uuid's all come from idl included in the sdk. We'd probably just need to figure out which generated source files were added to that lib. As another option, we might even be able to get away with using a uuid.lib from an older sdk.
Actually... what is being linked when you see that warning? Because a quick glance at the source tree shows we only really have one explicit OS_LIBS += ['uuid'] in accessible/interfaces/ia2/moz.build, and that's used to link a small shared library. If we're getting some implicit uuid.lib when linking, that's another matter.
I get really long link times (2 to 3 minutes) after touching one line of code in a .cpp file in dom/base.
Yeah this is definitely an issue with xul.dll uuid.lib would be brought in implicitly somehow given the use of COM by the Windows port. You can't really build a COM application without it. As an aside, I noticed that xul.dll was taking longer to link lately, but I didn't put two and two together until I tried compiling a different project with tup. The "bad" uuid.lib causes the linker to omit (or delete) the .ilk file (since it is forced to do a full link) but tup didn't like that because I had listed that file as one of the linker outputs.
This is specific to the anniversary update revision of the SDK (version 10.0.14393.0). If I use the previous SDK version (10.0.10586.0) I get an incremental link as expected.