On Wed, 16 Jul 2025, 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. > > > 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
Do you mean basename? I'm pretty sure that it's allowed to load dlls with the same basename, though you'd have to be careful (not do things like GetModuleHandle on just the basename). > 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. It kind of seems like you are talking about limitations of the PE import table and the Windows loader with respect to that, rather than what can be done with dlopen and the eventual LoadLibrary call underlying that. dlopen will resolve symlinks, and LoadLibrary takes a full path and should let you specify different paths with the same basename, if it came to that. Which it shouldn't, cygclang.dll would be a symlink to cygclang-20.1.dll and that's the basename that LoadLibrary would see. That being said, I do recognize this situation is pretty screwed up, and I'm trying to come up with a least-bad workaround that won't either mess with what upstream is doing, or cause unnecessary friction with Cygwin packaging (which including an unversioned dll of any sort in the versioned lib package would obviously do). 1) forget the other DLLs. libclang is the only one that thus far that has shown existing code that would break without an unversioned alias. 2) a package libclang containing usr/bin/cygclang.dll -> cygclang-X.Y.dll depending on package libclangX.Y, that can be upgraded or downgraded as desired. 3) clang-devel contains usr/lib/libclang.dll.a which has the dll name of cygclang-X.Y.dll, so things linking -lclang will end up with the real name in their import table. Someone would have to either explicitly try to link /usr/bin/cygclang.dll or not have the devel package installed to have the cygclang.dll symlink considered for linking. Does this make sense? Am I missing something that means this cannot possibly work to get that python binding to work?
