[Conda packaging] libcxx version and conda "run exports" on OSX

[SylvainCorlay]

Currently, the conda package for clang on OSX has a "strong run export" on libcxx, this means that any package built with clang will depend on the corresponding libcxx conda package at runtime. Most typically, the mechanism of "strong" run export is used to create a runtime requirement on the compiler runtime for artifacts built with this compiler.

The version of clang used to build packages at the moment is clang 14 and therefore, we are building the entire cling stack with clang 14, including clangdev 9! The main consequence is that cling 0.9, and clangdev 9 depends on libcxx 14 at runtime.

This poses two issues:

• libcxx uses some include_next statements to include headers having the same name in the sysroot. The problem when libcxx is installed as a conda package, is that this include_next bounces between the sysroot and the conda prefix! This is resolved in clang with https://reviews.llvm.org/D55500, but this patch was included in clang after release 9. A solution would be to backport this change to clang 9 and make it a patch on the recipe for clangdev on conda-forge.
• libcxx advertises a rather tight compiler support - and only guarantees support for the last two versions of clang, so that libcxx is only guaranteed to work with clang 13 and clang 14 - but probably not with clang 9 and cling 0.9...

In my opinion, this really suggests having a version of cling for each clang version, and is a great argument for the clang-repl effort. However, I would love to hear your thoughts on the problem at hand with cling being spearated from clang, and somewhat late on the undelying clang version in use.

[AngryMaciek]

Any progress on a clean solution? Is anyone else actually aware of this problem?