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. > 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
