On 17/07/2025 00:13, Jeremy Drake via Cygwin-apps wrote:
[...]
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.
I think the general pattern across Cygwin packages is: just don't
install those links, patch where necessary, try to educate upstream such
links aren't appropriate on PE.
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?
So, we have an existing (elderly) python-clang package, which already
patches this to operate in a sane way.
Can we just keep on doing that?
[1]
https://cygwin.com/cgit/cygwin-packages/python-clang/tree/3.7.1-cygwin-ctypes.patch
