[ITP] clangd

[Mark Geisert]

On 10/27/2026 6:54 AM, Takashi Yano via Cygwin-apps wrote:
> Hi Mark,
> 
> Thanks for having a look!
> 
> On Tue, 27 Oct 2026 02:53:08 -0700
> Mark Geisert wrote:
>> Hi Takashi,
>>
>> On 10/16/2026 11:29 PM, Takashi Yano via Cygwin-apps wrote:
>>> On Wed, 14 Oct 2026 00:29:53 +0900
>>> Takashi Yano wrote:
>>>> On Mon, 6 Jul 2026 15:34:05 +0900
>>>> Takashi Yano rote:
>>>>> On Sun, 18 Jan 2026 17:41:37 +0900
>>>>> Takashi Yano wrote:
>>>>>> On Sun, 18 Jan 2026 00:51:54 -0700
>>>>>> Brian Inglis wrote:
>>>>>>> On 2026-01-17 16:56, Takashi Yano via Cygwin-apps wrote:
>>>>>>>> clangd understands the C++ code and adds smart features to the editor:
>>>>>>>> code completion, compile errors, go-to-definition and more. clangd is
>>>>>>>> a language server that can work with many editors via plugins.
>>>>>>>
>>>>>>> Why can't you just add CLANG_PATCHES to or append them directly in PATCH_URI,
>>>>>>> as we do with other patch sources like Debian, Fedora, Gentoo, OpenSuSE, ...?
>>>>>>
>>>>>> Because clang directory is not a subdirectory of ${SRC_DIR}.
>>>>>>
>>>>>> llvm-project-21.1.4.src
>>>>>>     ├─clang
>>>>>>     ├─clang-tools-extra
>>>>>>     ├─cmake
>>>>>>     ├─compiler-rt
>>>>>>     ├─libc
>>>>>>     ├─libcxx
>>>>>>     ├─libcxxabi
>>>>>>     ├─libunwind
>>>>>>     ├─llvm              <----- ${SRC_DIR}
>>>>>>     ├─runtimes
>>>>>>     └─utils
>>>>>>
>>>>>> The clang patches are borrowed from clang package, the paths in the
>>>>>> patches assume the ${SRC_DIR} is in clang.
>>>>>>
>>>>>>> If you have a necessity to use src_patch_hook, then rather than generate
>>>>>>> CLANG_PATCHES values using eval, everywhere else in Cygport uses indirection
>>>>>>> ${!PATCH_PROJ} with PATCH_PROJ=CLANG_PATCHES; or avoid implementing an unused
>>>>>>> unnecessary future expansion design feature entirely and just use the variable
>>>>>>> directly in `for list in $CLANG_PATCHES`, only getting fancier when you really
>>>>>>> need to?
>>>>>>
>>>>>> Yeah, indeed. This src_patch_hook() is also borrowed from other package,
>>>>>> where the for loop is as follows.
>>>>>> 	for proj in clang llvm libcxx; do
>>>>>>
>>>>>> For this package, this mechanism is too complicated, as you said.
>>>>>
>>>>> clangd.cygport updated.
>>>>> Please continue to review.
>>>>
>>>> I've updated the base version of the package candidate to 22.1.8.
>>>
>>> It seems that the patches for LLVM and Clang are not necessary
>>> for building clangd. I've removed them. clangd.cygport has been
>>> much simplified.
>> I've taken a shot at building clangd using your latest clangd.cygport.
>> At the moment it's building module 651 out of 3418 (?!).  I noticed that
> 
> 3418 is normal.
> 
>> each cygport command I issue has output that starts with...
>>
>>> Traceback (most recent call last):
>>>    File "<string>", line 1, in <module>
>>> ModuleNotFoundError: No module named 'distutils'
>>> Traceback (most recent call last):
>>>    File "<string>", line 1, in <module>
>>> ModuleNotFoundError: No module named 'distutils'
>>> Traceback (most recent call last):
>>>    File "<string>", line 1, in <module>
>>> ModuleNotFoundError: No module named 'distutils'
>>> Traceback (most recent call last):
>>>    File "<string>", line 1, in <module>
>>> ModuleNotFoundError: No module named 'distutils'
>>
>> ...before showing the usual output from whichever cygport command runs.
> 
> However, this is not normal. This seems to be a python error message.
> The module 'distutils' was obsoleted and python 3.12 no longer provides it.
> 
> I guess some python modules are incorrect state in your environment.
> 
> But, wait, most of building steps do not need pyhton.
> Hmm, maybe due to the line `inherit meson python3` at the top of
> clangd.cygport file. What if you replace it with `inherit meson`?
> Inheriting python3 might be unnecessary.
> 
>> That's the only unusual thing I've seen so far.  I'll update you when
>> I've finished running the steps after 'cygport build'.
I started over with just "inherit meson" in the cygport file.  All steps 
completed without obvious errors.  I have a package-test completed.

However, there's something odd about clangd.exe.  It cannot be run or 
strace'd.  ldd can't process it, but cygcheck can.  Here's the log...

> /devel/usr/src/clangd-itp/clangd-22.1.8-1.x86_64/build/bin ./clangd
> -bash: ./clangd: cannot execute binary file: Exec format error
> 
> /devel/usr/src/clangd-itp/clangd-22.1.8-1.x86_64/build/bin strace -o foo ./clangd
> strace.exe: error creating process C:\cygwin64\usr\src\clangd-itp\clangd-22.1.8-1.x86_64\build\bin\clangd, (error 193)
> 
> /devel/usr/src/clangd-itp/clangd-22.1.8-1.x86_64/build/bin ldd ./clangd
> ldd: ./clangd: Bad file descriptor
> 
> /devel/usr/src/clangd-itp/clangd-22.1.8-1.x86_64/build/bin cygcheck ./clangd
> C:\cygwin64\usr\src\clangd-itp\clangd-22.1.8-1.x86_64\build\bin\clangd.exe
>   C:\cygwin64\bin\cygc++-1.dll
>     C:\cygwin64\bin\cygwin1.dll
>       C:\Windows\system32\KERNEL32.dll
>         C:\Windows\system32\ntdll.dll
>         C:\Windows\system32\KERNELBASE.dll
>     C:\cygwin64\bin\cygunwind-1.dll
>     C:\cygwin64\bin\cygclang_rt.builtins-1-x86_64.dll
>   C:\cygwin64\bin\cygz.dll
>   C:\cygwin64\bin\cygzstd-1.dll
> 
> /devel/usr/src/clangd-itp/clangd-22.1.8-1.x86_64/build/bin uname -a
> CYGWIN_NT-10.0-19045 zotac 3.7.0-0.637.g1aeae4f14a45.x86_64 2026-10-27 06:21 UTC x86_64 Cygwin

Windows error 193 is ERROR_BAD_EXE_FORMAT, so that matches.  Any idea 
what might be amiss in this 1.9GB executable?

..mark