@pirama-arumuga-nainar I think that we can probably build this along with LIBOMP_ENABLE_SHARED in our build.py scripts. Do you know why we might not have enabled this (other than conforming with previous libomp.a from GCC)?

Yes, we only included libomp.a to match gcc, and the reasoning that someone can make a shared library out of it if necessary.

But that doesn't seem to be the case as I figured when turning LIBOMP_ENABLE_SHARED in our build script. I think it's a reasonable request and will address it.

In terms of NDK releases, I'd say r22 sounds reasonable (or whenever the NDK clang gets updated past the one planned for r21).

It seems the OpenMP CMake files are not setup to simultaneously build both a static and a shared library, mainly due to limitations in the build system. For e.g., LIBOMP_LIBRARY_SUFFIX is set in openmp/runtime/CMakeLists.txt and gets used in openmp/runime/src/CMakeLists.txt as if there's either just a shared or a static lib.

I am not too familiar with CMake - so if anyone can suggest a simple way to refactor this setup, that'd be useful. Worst case, we can just build shared and static libraries in separate CMake invocations (like we do for the NDK vs. the platform).

(r22 corresponds roughly with Q4)

I decided to just clone/duplicate another build to get the .so.
https://android-review.googlesource.com/c/toolchain/llvm_android/+/1012416 is the change. @herbakamil can you test the libraries from https://ci.android.com/builds/submitted/5715392/linux/latest/clang-5715392-linux-x86.tar.bz2?

Can I ask how one can use it? This is whole clang compiler, should I somehow config the ndk to use this compiler instead of the bundled one?

You can copy the libomp.so from this package adjacent to the libomp.a in an NDK's Clang directory (and maybe delete the libomp.a to ensure the shared object gets used?). I think that should mostly work since openmp runtime doesn't change that frequently.

I can confirm that it works, but you obviously need also to instruct android studio to copy libomp.so into apk

For now, add it to your jniLibs like you would for ASan: https://developer.android.com/ndk/guides/asan#running

Getting Gradle fixed will take some time. 3.6 is the absolute earliest it could happen (3.5 is already quite locked down).

I understand, I can confirm that after adding to jniLibs it indeed works.

We've found that setting KMP_DUPLICATE_LIB_OK (see here) works around the crash. Is there any reason to think that would cause other problems?