libiomp5.so conflicts with openmp package

[hubutui]

Hey, it seems that both mkl-dnn and openmp will install libiomp5.so into system as /usr/lib/libiomp5.so, which leads to file conflicts. Any suggestion to deal with this confilict? According to https://github.com/llvm/llvm-project/blob/master/openmp/runtime/CMakeLists.txt#L360, libiomp5.so is just a soft link to libomp.so for backward compatibility. Not sure if I build with LIBOMP_INSTALL_ALIASES=OFF would break anything.

[shelleygoel]

Hi @hubutui I think MKL-DNN doesn't install OMP runtimes. From documentation

"Intel MKL-DNN uses OpenMP runtime library provided by the compiler."

Could you please provide details on how you are building MKL-DNN?

[hubutui]

I install mkl-dnn from arch4edu repo, which uses PKGBUILD to build mkl-dnn. To reproduce:

1. a archlinux environment with devtools, maybe a docker image.
2. mkdir mkl-dnn, cd mkl-dnn, wget https://github.com/arch4edu/arch4edu/raw/master/mkl-dnn/PKGBUILD
3. build with extra-x86_64-build -- - --nocheck

Then we get a package file mkl-dnn-0.19-4-x86_64.pkg.tar.xz. untar this tarball, we could see that usr/lib/mklml/libiomp5.so. libiomp5.so is installed to /usr/lib if we do not manual mv it to mklml subfolder, as line 49-53 shows in the PKGBUILD file.

mkl-dnn-0.19-4-x86_64-build.log is the build log, corresponding to the build function in the PKGBUILD file.
mkl-dnn-0.19-4-x86_64-package.log is the log of package function in the PKGBUILD file, where we use make install to install mkl-dnn to fakeroot to create a package.

[hubutui]

according to #102, mklml is a subset of mkl, which is provided in the release page as lib tarball. So, if I build mkl-dnn linking to mklml, then in the make install step, libiomp5.so from mklml is installed to systemd. That's is the reason that I got file conflicts. Maybe I should report this this to mkl upstream?

[vpirogov]

@hubutui, you are right, when Intel MKL-DNN v0.x is built with libmklml it does install OpenMP runtime into /usr/lib. This should not be the case as OpenMP runtime is shared dependency and should be managed as such. The workaround implemented in PKGBUILD makes perfect sense.

This is not an issue with v1.0 as it does not install OpenMP runtime.

[vpirogov]

Closing as the issue is resolved in v0.20. Please let me know if you want us to do any changes to v0.20.