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

Martin Storsjö via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Tue Feb 21 00:41:59 PST 2023

mstorsjo added a comment.

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

> I think the step is about builds that follow the "native" Windows import library model and have changed the description to say that. 'MSVC style' is OK too, but I think the term is a bit vague and imprecise, e.g.

Well I also find the term "native Windows import library model" extremely vague here - to the point that I simply don't understand on a technical level what you refer to. Mingw toolchains also use the same sort of Windows import libraries as MSVC style based toolchains. What part of the import library model do you consider to differ?

> you can build Windows DLLs with import libraries from assembly code as well.

Right, but it doesn't refer to MSVC as in the C/C++ compiler, but it refers to the collective tool interface model (mingw or msvc), where e.g. clang based tools can be used both with a MSVC style interface (with clang-cl, llvm-lib, lld-link, etc) and a mingw style interface (with clang, llvm-ar, ld.lld, llvm-dlltool). In that case, it's primarily the tool interface which affects what you can and can't do. Within CMake, this nuance is primarily signalled with `if (MSVC)`.

(With that in mind, it's indeed a bit of an issue that llvm-lib doesn't support the `/def` flag.)



More information about the Openmp-commits mailing list