Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[openmp] Fix building for mingw targets after import library changes
06d9bf5 (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. Differential Revision: https://reviews.llvm.org/D143992
- Loading branch information