Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relationship between clangdev and libclang #196

Open
h-vetinari opened this issue Dec 18, 2022 · 2 comments
Open

Relationship between clangdev and libclang #196

h-vetinari opened this issue Dec 18, 2022 · 2 comments

Comments

@h-vetinari
Copy link
Member

Currently clangdev hard-pins the libclang-output.

Since clang is the default compiler on osx, this makes it hard to compile against libclang (e.g. qt, resp. its reverse dependencies), because an unpinned host-dep on libclang will currently pick up a run-export of libclang >=15.0.6,<16, which can then not be installed on osx in a recipe that requires compilers, because we don't yet have clang 15 fully ready.

Since libclang has been abi-compatible since LLVM 13 (and we specifically have a libclang13 that libclang depends on), I guess we could loosen the dependence of clangdev on libclang to:

--- a/recipe/meta.yaml
+++ b/recipe/meta.yaml
@@ -95,7 +95,7 @@ outputs:
         - {{ pin_subpackage("clang", exact=True) }}
         - {{ pin_subpackage("clangxx", exact=True) }}
         - {{ pin_subpackage("clang-tools", exact=True) }}
-        - {{ pin_subpackage("libclang", exact=True) }}
+        - libclang{{ libclang_soversion }} >={{ version}}
         - {{ pin_subpackage("libclang-cpp", exact=True) }}
         - libcxx {{ cxx_compiler_version }}  # [osx]
         - llvmdev =={{ version }}

Thoughts @conda-forge/clangdev?

PS. Longterm we could perhaps include libclang in the global pinning like we do for numpy (i.e. use the oldest abi-compatible build for our current compilers).
PPS. It's still not clear what will happen in upstream LLVM with the possibility to build (the equivalent of) libclang13. The original RFC got reverted for LLVM 15, and since it was very late in the release there's just an option to switch it back on, but that's not considered long-term stable. See thread & summary here, please join the discussion if you think knowing when libclang's ABI changes (esp. if less often than every major) is important.

@h-vetinari
Copy link
Member Author

Since libclang has been abi-compatible since LLVM 13 [...]

Well, this turns out to be false, unfortunately: llvm/llvm-project#60270

I guess we haven't seen any breakage yet, though this is the kind of risk we run unfortunately, seeing that what we're doing is not the default upstream anymore since LLVM 15 (and thus prone to faster bitrot).

CC @isuruf

@bonzini
Copy link

bonzini commented Jan 25, 2023

I guess we haven't seen any breakage yet, though this is the kind of risk we run unfortunately

Yeah, the breakage is subtle and unlikely to cause trouble outside a testsuite (I originally found it via KyleMayes/clang-rs#45), but it sucks nevertheless...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants