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

Sun Mar 26 14:53:56 PDT 2023

mstorsjo added a comment.

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

> The source of problem is the attempt to re-use the results of the first build in order to avoid rebuilding the sources the second time to just re-generate the import library. This is being done by feeding the main build's import library as a source to the second one (@301) with CMAKE ending up assuming the library is located where the sources are, hence the reference to `projects/openmp/runtime/src/libomp.dll.lib` instead of what should be `lib/libomp.dll.lib` in the LLVM based build.

Thanks for investigating this bit, that makes the issue much clearer!

> At this point, I do not see a good way to just repoint CMAKE to the first build's drop location, and reusing its library would likely require doing a custom target. I think a cleaner and better solution is to simply rebuild the second one from sources (it's a small build). I'll submit a patch.

While the library is rather small and duplicate compilation isn't that much extra work, I took a shot at making it work with both directory layouts, and I think I got it working; we just need to prefix the original import library with an absolute path to the directory where it's stored. I'll post an alternative patch that does this.

FWIW, in one sense we shouldn't really need these files as input to the `lib` command at all - `lib` can generate an import library from a def file just fine, without any object files or preexisting library at all - just `lib /def:libomp.def /out:libomp.lib`. Unfortunately, cmake doesn't really accept a library target without any source files (where the only "source file" is passed in as the def file via `STATIC_LIBRARY_OPTIONS`). And once you pass one object file to `lib`, it will check that all the exported symbols exist, so we can't just pass a dummy object file, we do need to pass all these (as you've noticed). FWIW I tried to see if there are other solutions to this, and found https://gitlab.kitware.com/cmake/cmake/-/issues/21638 - so it doesn't seem that there are any good solutions. Although generating the import library with a custom target might not be that bad either (I might give it a try).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144419