On 2025-07-16 10:59, ASSI via Cygwin-apps wrote:
Jeremy Drake via Cygwin-apps writes:
How should the libclang python binding work then (it uses ctypes)?
I don't know, but Cygwin can't be the only platform having this
peculiar problem unless they also gnore it elsewhere.
https://github.com/llvm/llvm-project/blob/6d0f573535e27171e4ef927baeab3edc928beebb/clang/bindings/python/clang/cindex.py#L4348-L4379
…which apparently they gleefully do.
As the preceding section makes clear, compatibility is the user's problem, they
have to version their source to run with whatever features the current library
happens to support! 8^p
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.
So their libary is infinitely backwards compatible or they expect elves
to work out what their ABI requirements are? If the ABI was stable like
that then the library version would never change anyway and if not I
don't see how they deal with it in the general case.
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 ;)
Again, the DLL ultimately loaded must have a unique name, which
precludes any trickery that hardlinks or copies it unless you can be
sure that at runtime you really only need a single version, which gets
you back to square 1. It may be that there's a workaround using what is
termed "assemblies", but none of that sounds like it would be easily or
quickly implementable in a way thast can be used by Cygwin.
--
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
