On 2025-07-15 23:28, Jeremy Drake via Cygwin-apps wrote:
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 ;)
Use alternatives and/or a postinstall script?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
