mingw64/mingw-w64-x86_64-openmp 10.0.0-1 invalid content of /mingw64/lib/libomp.a

[mkviatkovskii]

Hello! Thank you very much for you work. Latest version of MinGW Clang comes with OpenMP support, and package contains two libraries:

• /mingw64/bin/libomp.dll
• /mingw64/lib/libomp.a

Linking with static library is not possible (it does not contain required symbols), so I am talking about linking to shared library.

GNU ld allows to link directly with /mingw64/bin/libomp.dll, but Clang LLD requires an import library for it (libomp.dll.a):

$ clang++ -fuse-ld=ld -fopenmp -L/mingw64/bin main.o libmath.a  # works fine
$ clang++ -fuse-ld=lld -fopenmp -L/mingw64/bin main.o libmath.a 
lld: error: lld doesn't support linking directly against C:/msys64/mingw64/bin\libomp.dll, use an import library
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

But in fact required libomp.dll.a is already inside the /mingw64/lib/libomp.a for some reason (see the last line):

$ ar t /mingw64/lib/libomp.a
kmp_import.cpp.obj
libomp.dll.a

So if I just extract this static library and copy libomp.dll.a to /mingw64/lib, everything works fine:

ar x /mingw64/lib/libomp.a
cp libomp.a.dll /mingw64/lib/ 
clang++ -fuse-ld=lld -fopenmp main.o libmath.a  # works fine

I don't know what is the best way to patch this (add such extraction to the package creation script, or add patch to the Clang OpenMP CMake script, or maybe something else), so just posting this information.

[ghost]

I can reproduce; $ uname -a MINGW64_NT-10.0-18363 GAMERTRON-3000 3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys

Without the workaround, build of latest Darktable master fails. With the workaround, it succeeds.

On my system

ar x /mingw64/lib/libomp.a

produces libomp.dll.a instead of libomp.a.dll but indeed copying the file to /mingw64/lib/ still works as a fix. Thank you!

[mati865]

Both libomp.a and libomp.dll.a are accepted as import library suffixes and LLD 10 doesn't give me an error with clang++ -fuse-ld=lld -fopenmp.

Without the workaround, build of latest Darktable master fails.

That is CMake issue https://github.com/msys2/MINGW-packages/issues/6394 but it'd be nice to have the more correct implib format.

[revelator]

looks like libomp.a is an import library even though it should have been named libomp.dll.a this seems to also have been the cause for inkscape to fail building with cmake as cmake picked it up as the library for gcc's -fopenmp switch.

[mati865]

@revelator libomp.a currently is an archive that contains import library (libomp.dll.a) and kmp_import.cpp (because MSVC is dumb). While it's not the preferred extension for import library it's still within "spec". Recent CMake versions don't follow that and in the result cannot find the import library.

That said I have WIP patch for openmp that will fix it.

[revelator]

seems to be quite a few problems with cmake recently hmm ...

[mati865]

@revelator it's unrelated to cmake version. Upstream had to make weird hack to make it work on msvc.

[revelator]

Ok that explains it.

[mati865]

Fixed by https://github.com/msys2/MINGW-packages/pull/6534