Shipping `openmp` with `clang` about aggregate HOT 12 OPEN

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.

from aggregate.

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

from aggregate.

Friendly nudge 😉

from aggregate.

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

from aggregate.

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.

from aggregate.

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!

from aggregate.

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?

from aggregate.

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

from aggregate.

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

from aggregate.

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 -

from aggregate.

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

from aggregate.

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

from aggregate.