On Thu, 10 Jul 2025, Takashi Yano via Cygwin-apps wrote: > On Wed, 9 Jul 2025 23:34:37 -0700 (PDT) > Jeremy Drake wrote: > > On Wed, 9 Jul 2025, Jeremy Drake via Cygwin-apps wrote: > > > > > I just saw you updated some patches. Most of the patches are now already > > > upstream and are included to backport to 20.1.x. > > > (https://github.com/msys2/MSYS2-packages/blob/master/llvm/README-patches.md) > > > Specifically, your modification to the clang 0110 patch adding a Cygwin > > > toolchain should be a followup patch because 0110 patch is > > > https://github.com/llvm/llvm-project/commit/52924a2d7255cdd280b2b82dad8616e01fe065da > > > > Oh, I have commit access to llvm-project now too, so if you wanted to make > > a PR there I could review it. I think they're getting close to the > > scheduled time for branching off for 21.x. That'll be nice because there > > are too many patches being backported to 20.x right now ;) > > I have just created a PR: > https://github.com/llvm/llvm-project/pull/147960 > >
There is another PR in progress that adds more symlinks for DLLs on Cygwin. This is a little bit confusing from a packaging standpoint because these are un-versioned dll names cygLLVM.dll -> cygLLVM-20.dll, or cygclang.dll -> cygclang-20.1.dll. These are added for code that uses dlopen and friends to call the C API (apparently the python bindings to libclang do this). How do packages handle this situation? They can't be in the libclang20.1 package because they'd conflict with a later libclang21.1 package providing the same names. I was thinking about putting them in the -devel packages, but it may be overkill to require users of the python libclang bindings to install the -devel package. Maybe the llvm and clang packages, alongside the tools, since there can only be one version of those at a time also?
