Shipping `openmp` with `clang`

[jakirkham]

It appears that openmp does not ship with clang from defaults (particularly on macOS). In contrast, it does ship with gcc from defaults (particularly on Linux). It would be nice to have OpenMP enabled compilers ship by default on all OSes and have the OpenMP run time libraries automatically included as well (when using {{ compiler(...) }}).

[nehaljwani]

There is a package for macOS. It's called llvm-openmp

[jakirkham]

Ok, so actually I didn't know how it was named in defaults. This is helpful. We've been using the one from conda-forge presently, which is just called openmp.

One of the most common questions that we get in conda-forge when building numeric code is how to enable OpenMP support. Our solutions have varied from use gcc, use our copy of openmp (macOS specifically), and now lately use defaults compilers with our copy of openmp. As LLVM has a solution for this, it has been tested for a while, and we are already packaging it as part of the LLVM build, it would be good to just ship LLVM's OpenMP implementation with the compiler and as part of the compiler runtime library.

Compare this to other platforms. When a user builds a recipes with say {{ compiler("c") }} on Linux, it will install gcc and libgcc (add appropriate prefix/postfix here), which includes libgomp. So OpenMP just works on Linux. Similarly on Windows, Visual Studio includes OpenMP support out-of-the-box and our runtimes include the appropriate DLLs, vcomp. However on macOS, the experience remains less than straightforward, users need to add llvm-openmp explicitly (and maybe pin it?). It would be better to just include this with the clang compiler on macOS by default and include the libomp with run_exports so it just gets pulled along with anything else built.

[jakirkham]

Friendly nudge 😉

[nehaljwani]

There is a plan to upgrade the llvm compilers soon. If @mingwandroid agrees, the changes suggested by you may be considered during the upgrade. 😜

[mingwandroid]

I'd actually rather we split libgomp from GCC! But I don't really mind either way as in defaults we are adding llvm-openmp for macOS in a few places and it's pretty ugly.

[mingwandroid]

The reason for splitting is in case anyone wants to do a matrix build against different implementations but then again that's probably too much work for all of us!

[jakirkham]

Well if we can have a consistent solution between macOS and Linux, that would be very helpful.

A split friendly option might be to have {{ compiler("openmp") }}.

To make sure I understand, do you mean mixing GOMP with the LLVM toolchain or vice versa for GCC? Assuming I'm understanding this correctly, what are the use cases for this?

[mingwandroid]

There no technical reason to tie the compiler used to openmp implementation that I'm aware of. That is all.

We're looking into llvm/clang for Linux for example..

[jakirkham]

As a note, people are needing to add the include path for llvm-openmp specifically for the compilers. Otherwise they get error messages about the compilers not being able to find omp.h. Would it be possible to include this in the compiler flags?

https://github.com/conda-forge/nfft-feedstock/pull/10/files#diff-44a73bcc045c193c3bd45da87994b03b

[mingwandroid]

Hi @jakirkham, nfft is doing it wrong; this is an example of how to correctly use llvm-openmp.

echo -e "#include <omp.h>\nint main() {}" | CONDA_BUILD_SYSROOT=/opt/MacOSX10.9.sdk $CC -x c -fopenmp=libomp -

[mingwandroid]

There's one gotcha, llvm-openmp needs to go into build and run requirements, but that's not a big deal IMHO.

[jakirkham]

Adding it to build in addition to host and run seems to work without that hack. Thanks @mingwandroid.