[ITA] llvm

[Jon Turney]

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