load headers in right spot for all versions of clang?

[beckermr]

Right now, if I have clang 4.0.1 in my env, but am using llvm-openmp 8.0.1, the compiler won't be able to find its headers at $PREFIX/lib/clang/4.0.1/include/omp.h because the version numbers differ. (The llvm-openmp package has them at $PREFIX/lib/clang/8.0.1/include/omp.h in this case.)

We should either force the versions to match or we need to link them properly somehow.

[beckermr]

@isuruf @jakirkham for viz

This is why the xgboost build with cmake was failing.

[beckermr]

I think adding run_excluded with clang != <llvm-openmp version> would do the trick, but IDK if we want the constraint.

[isuruf]

A PR to conda-forge-pinning would fix it.

[beckermr]

Right, but in the latest gfortran build for osx, you pinned llvm-openmp to 8

https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/blob/master/recipe/meta.yaml#L61

Do we need to globally remove all of these pinnings in conda forge?

[beckermr]

Given that we just rebuilt a bunch of packages with that pin, changing it now would require another rebuild of ~100 repos or so.

[isuruf]

Ah, yes. Usually omp.h will be found because it is also in $PREFIX/include, but in this case -I$PREFIX/include is not sent by cmake

[beckermr]

I actually think my comment above is wrong. I think the dep is in libgfortran, not the parent package, so I don't think the rebuild would be needed for those.

So we could

1. fix gfortran to not specify a version
2. add a global pin to 4

Then when we update pinnings, we have to make sure to move them together.

[isuruf]

We can't do 1. because a newer llvm-openmp is actually needed.

[beckermr]

:/ ok.

Well then I think we need to adjust this repo to patch the right path with an activation script or something.

[beckermr]

And ofc @isuruf has better ideas :)

from him:

1. set CPATH
2. treat this as a bug in cmake

[feltech]

Not sure if this is related or a separate issue.

With clang installed

$ ls ./lib/clang/
16

then

$ mamba install llvm-openmp
...
$ ls ./lib/clang/
16  16.0.6
$ find ./lib/clang/16.0.6/
./lib/clang/16.0.6/
./lib/clang/16.0.6/include
./lib/clang/16.0.6/include/omp.h

This is causing FindOpenMP.cmake to fail to locate omp.h because the 16.0.6 directory is not in the compiler's include search path, whereas the 16 directory is.

This looks like a bug in the llvm-openmp package, however...

As mentioned, omp.h is also made available in ./include, which clang doesn't search by default. This is where my knowledge gets fuzzy, since I'm not clear on the logic of how or why default compiler include paths are configured.

[h-vetinari]

compiler-rt uses the same pattern (i.e. 16.0.6, not 16), so I think this is intentional, and should be working.

I appreciate that you checked if there are existing open issues for you problem, but in this case it's a really tenuous relation. Please open a new issue and provide all the requested information (principally conda list and conda info).

[feltech]

I appreciate that you checked if there are existing open issues for you problem, but in this case it's a really tenuous relation. Please open a new issue and provide all the requested information (principally conda list and conda info).

Done in #99 - looks like its mostly down to a change in install location for clang 16.