On Wed, 16 Jul 2025, ASSI via Cygwin-apps wrote: > Jeremy Drake via Cygwin-apps writes: > > There is another PR in progress that adds more symlinks for DLLs on > > Cygwin. This is a little bit confusing from a packaging standpoint > > because these are un-versioned dll names cygLLVM.dll -> cygLLVM-20.dll, or > > cygclang.dll -> cygclang-20.1.dll. These are added for code that uses > > dlopen and friends to call the C API (apparently the python bindings to > > libclang do this). > > Shoot it down. These symlinks are idiocy since they will not work in > general, depending on the type of symlink used and the loader that tries > to process them. ATWIL and all that, but there is no ldconfig or > similar here. > > > How do packages handle this situation? > > Not at all. Such nonsense must not be packaged.
How should the libclang python binding work then (it uses ctypes)? https://github.com/llvm/llvm-project/blob/6d0f573535e27171e4ef927baeab3edc928beebb/clang/bindings/python/clang/cindex.py#L4348-L4379 No other platform includes a version number there. It's pretty clear that the intent of the PR is to then add elif if name.startswith("CYGWIN"): file = "cygclang.dll" I don't think they really want "cygclang-20.1.dll" and have to bump that with every release. You might say, only bump the soversion on an ABI-breaking change, but changing the release processes of llvm-project is pretty far outside the scope of adding Cygwin platform support ;)
