[PATCH] D60094: [MSVC] If unable to find link.exe relative to MSVC, look for link.exe in the path

Mon Apr 1 23:32:42 PDT 2019

mstorsjo marked an inline comment as done.
mstorsjo added inline comments.

================
Comment at: lib/Driver/ToolChains/MSVC.cpp:493
       C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+      linkPath = TC.GetProgramPath("link.exe");
+    }
----------------
rnk wrote:
> amccarth wrote:
> > The comment above explains one reason why we shouldn't use link.exe on the path.
> > 
> > If it is an appropriate fallback, modify the comment or add another one here explaining why this is better than failing.  I think you hit on it in the patch summary, but it should be captured in the code.
> Right, and this code block is inside some crazy getenv check for USE_PATH_LINK, so I think we don't want to do a path search here. Then again, I bet someone added that because they wanted clang to just do a path search. I guess, there's your workaround.
Sorry for the confusion - the getenv USE_PATH_LINK thingie there isn't present upstream, it's my other initial hack to get around this issue; I should have reordered the patches before making this diff.

So that getenv hack is an ugly but convenient (for me) way around the issue. Another alternative is to use `-fuse-ld=link.exe` (which happens to miss the `Linker.equals_lower("link")` check).

Prior to switching to lld, how did chromium do this? I presume the cross compilation setup did exist already before lld. Although in practice I guess most people don't use (clang-)cl for linking but just invoke `link` directly so maybe it didn't matter at all.

Another approach (which also works fine for me) is to look for `$(dirname $(which cl))/link.exe`.

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60094/new/

https://reviews.llvm.org/D60094