[PATCH] D151188: [lld] Find resource and lib dir

[Tobias Hieta via Phabricator via llvm-commits]

thieta added a comment.

Hi everyone, and thanks for your input. My goal with this patch is to let lld-link find the rest of the files from the toolchain without teaching every build system in the world extra logic. I have thought about the different ways to handle this, and this one seemed the least complicated, to be honest. If we wanted to directly re-use the clang driver logic with `clang -link` or similar - we would have to teach the build systems to call clang instead of lld-link, we would have to teach it to pass --target to that, or we would have to parse the machine information out of the object files in clang as well (non-starter I think).

While it would be better if we didn't need to add this logic to lld at all, I don't think we can change the paradigm that Microsoft has with its toolchain already. There is already precedent for this - if you look in the WindowsDriver library, we already probed for the visual studio installation and added those default search paths in lld. This expands that functionality to add (less complicated) logic to find the toolchain library paths. So I don't think this is way out of line.

There are other ways to do this: We could have lld execute clang in the same directory as itself to query the driver about the paths. I'm not sure I love that, but it would solve the problems of not duplicating logic or linking to things left and right.

The logic in lld could be much simpler as well. Instead of constructing a Triple (the worst part of this patch IMHO), we could probe for static directories `x86_64/i386/aarch64-pc-windows-msvc/gnu`. This won't be bulletproof but would solve 95% of the users' use-case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151188