[Openmp-commits] [PATCH] D144419: Improvements to the OpenMP Windows build

[Martin Storsjö via Phabricator via Openmp-commits]

mstorsjo added a comment.

In D144419#4142780 <https://reviews.llvm.org/D144419#4142780>, @vadikp-intel wrote:

> Updated the controversial comment to promote toolchain equity.

Thanks. Although, it's not about promoting equality or something like that, it's just about using precise terminology.

Anyway, the updated comment seems ok to me - thanks!

In D144419#4141367 <https://reviews.llvm.org/D144419#4141367>, @hans wrote:

>> Although I guess it's possible to build with something like `-DCMAKE_AR=lib.exe` to force a preference for the tool which does support the `/def` option.
>
> Just `-DCMAKE_AR=lib.exe` doesn't seem to work, as it needs the full path.

Right - that's annoying and inconsistent in cmake that those tools need to be specified with the full path - and the equivalent of `-DCMAKE_AR=$(which llvm-ar)` isn't trivial in bat files...

> Should we revert D143431 <https://reviews.llvm.org/D143431> in the meantime?

Yeah I guess that's one option.

As for alternative ways forward - I believe implementing the `/def` option in llvm-lib is a bit more messy than one would want; in MS tools, `lib.exe` is just a thin wrapper over `link.exe`, while llvm-lib resides within llvm but lld is a separate project. But it might be possible to hoist those parts of the import lib creation logic from lld into llvm (I think a fair bit of it already has been moved there) to facilitate implementing this option.

But as noted earlier, lld-link doesn't seem to actually produce import libraries that link by ordinal anyway, so this step isn't really necessary there. So if we'd have linker identification in cmake here (not sure offhand if cmake provides that out of the box?), we could just skip the extra import lib step for now too.


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

https://reviews.llvm.org/D144419