[FR] dynamic OpenMP

[herbakamil]

Is your feature request related to a problem? Please describe.
Currently OpenMP is only available statically. We had a problem that different teams prepared libraries using OpenMP and when integration team combined them in a single Android Java app they were failing because OpenMP didn't like the fact that there were two instances of it.

Describe the solution you'd like
I would like to have the flag allowing me to link openmp dynamically into my Android NDK app

Describe alternatives you've considered
We've made experiment with downloading some old dynamic version of OpenMP and linking it with our module and it even worked but it would be hard to enforce such solution on other teams.

Additional context

[stephenhines]

@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)?

[pirama-arumuga-nainar]

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.

[herbakamil]

Do you have any expectations about the timeline? When such feature will be enabled? Q4 or rather 2020 (and which quarter)?

…

On Mon, 8 Jul 2019 at 19:40, pirama-arumuga-nainar ***@***.***> wrote: 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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1028>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AECGGAL4ZUZEWHIP3ULXRPDP6N3YZANCNFSM4H4ENALQ> .

-- Kamil Herba skype herba.kamil +48 88 5050 996

[pirama-arumuga-nainar]

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).

[DanAlbert]

(r22 corresponds roughly with Q4)

[pirama-arumuga-nainar]

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?

[taki-jaro]

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?

[pirama-arumuga-nainar]

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.

[taki-jaro]

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

[DanAlbert]

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).

[taki-jaro]

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

[paleozogt]

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?