I think this is not a particular issue to clangd, but to every llvm binary built from CMake that ends up getting configured with llvm_setup_rpath, which is called by llvm_add_library that brings up this behavior.

If something like libc.so.6 exists in current directory, clangd will mistakenly try to load it.

I don't see clangd is doing anything wrong: if you put clangd binary somewhere under the system directory e.g. /usr/local/bin/clangd, then /usr/local/lib or /usr/lib is expected to have your glibc libraries installed; otherwise, the path that causes such confusion for clangd is probably inappropriate: that looks more like an independent software collection (e.g. /opt/rh/... compared to your system's default), and you should build/use the clangd that matches the version of that glibc.

@zyn0217 The problem is clangd shouldn't search the working directory(where it is executed) for libraries.
If I put clangd binary in /usr/local/bin, and put main.c and libc.so.6 in ~/myproject/. Then execute nvim ./main.c, which execute /usr/local/bin/clangd in ~/myproject. It will search $ORIGIN/../lib(/usr/local/lib in this case) first.But Glibc shouldn't lies in /usr/local/lib.Then clangd will search through ~/myproject/ and find my libc.so.6. Why does it search my project first instead of go directly to /usr/lib?

Honestly, I don't see where the trailing colon gets added from the cmake script. Where did you get your clangd binary? Was that from our github release page?

I get it from github release.

https://github.com/clangd/clangd/releases/download/17.0.3/clangd-linux-17.0.3.zip

I have searched some documents, and now I believe this is a feature of CMake that helps replace rpaths after installing a target. See this and this.

AFAIU, the trailing colons will be added by CMake automatically if the target would get installed and BUILD_RPATH is set, and they will be replaced at the installation step. OTOH, our CI of building clangd provides the artifacts without performing installation, which leaves behind the trailing colons to the released binaries.

To quickly reproduce such behavior of CMake, one can create the following CMakeLists.txt and a C++ file named main.cpp.

cmake_minimum_required(VERSION 3.20)

project(testing)

set(_build_rpath "\$ORIGIN/../lib")

add_executable(main main.cpp)
target_compile_options(main PUBLIC "-std=c++17")

set_property(TARGET main APPEND PROPERTY BUILD_RPATH "${_build_rpath}")

install(TARGETS main)

int main() {}

then running the command cmake --build ./Build --verbose --clean-first would give us such:

[2/2] : && /usr/local/bin/clang++  -fuse-ld=mold CMakeFiles/main.dir/main.cpp.o -o main  -Wl,-rpath,"\$ORIGIN/../lib:"

(Note the trailing colon, and it will be gone if we remove the install command.)

That said, I don't have a better idea of resolving this issue. Configuring LLVM with CMAKE_NO_BUILTIN_CHRPATH=OFF appears promising, but that makes it spit out configuration failures on my Linux system, many of which are like:

The install of the Remarks target requires changing an RPATH from the build
  tree, but this is not supported with the Ninja generator unless on an
  ELF-based or XCOFF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH
  variable may be set to avoid this relinking step.