This is an archive of the discontinued LLVM Phabricator instance.

[openmp] Fix building for mingw targets after import library changes
ClosedPublic

Authored by mstorsjo on Feb 14 2023, 1:57 AM.

Details

Summary

06d9bf5e64d472db5485815d9c3f70631064bb25 (https://reviews.llvm.org/D143431)
did a large restructuring of how the import library is created;
previously, a second step to tweak the import library was only
done for MSVC style targets, but after this commit, that logic
was applied for mingw targets too.

Since LIBOMP_GENERATED_IMP_LIB_FILENAME and LIBOMP_IMP_LIB_FILE
are equal on mingw targets (both are "libomp.dll.a", while they
are "libomp.dll.lib" and "libomp.lib" for MSVC targets), this caused
a conflict, with errors like this:

ninja: error: build.ninja:875: multiple rules generate runtime/src/libomp.dll.a [-w dupbuild=err]

Skip the logic with a second step to recreate the import library
for mingw targets. The MSVC specific logic for this relies on
running the static archiver with CMAKE_LINK_DEF_FILE_FLAG, which
with MS lib.exe (and llvm-lib) ignore the input object files and
just generates an import library - but mingw style tools don't
support this mode of operation. (By attemptinig the same, mingw tools
would generate a static library with the def file as one member.)
With mingw tools, the same can be achieved by invoking the dlltool
executable instead.

Instead of adding alternative logic for invoking dlltool, just skip
the second import library step, since neither GNU nor LLVM mingw
tools actually generate import libraries that link by ordinal - so
there's no need for a second import library.

Diff Detail

Event Timeline

mstorsjo created this revision.Feb 14 2023, 1:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2023, 1:57 AM
mstorsjo requested review of this revision.Feb 14 2023, 1:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2023, 1:57 AM
Herald added a subscriber: sstefan1. · View Herald Transcript

Does anyone want to comment on this one, or should I just go ahead and revert D143431 to unbreak my continuous builds, and we can fold this into an updated version of that patch?

I don't know too much on Windows, but it looks reasonable to me. Better to wait for @jlpeyton and @natgla.

The patch looks OK to fix the mingw build for now. We have work in flight to address a few issues brought up here, e.g. kmp_import, the need to build the second set of sources and .def support outside of the MSVC compatible toolsets (e.g. llvm-lib) that may further touch on this particular script.

The patch looks OK to fix the mingw build for now.

Ok, thanks! Would you mind marking it as approved, before I go ahead and commit it?

We have work in flight to address a few issues brought up here, e.g. kmp_import, the need to build the second set of sources and .def support outside of the MSVC compatible toolsets (e.g. llvm-lib) that may further touch on this particular script.

Ok, that sounds good to hear! Feel free to subscribe me to such patches, and I'll try to chime in if I have something to add on it.

Looks good. I will include Martin in the subsequent reviews here.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 14 2023, 2:48 PM
This revision was automatically updated to reflect the committed changes.