The release was broken because the macos-latest image was upgraded from macos-12 to macos-14, resulting in AppleClang being updated from version 14 to 15. To resolve the problem, modify macos-latest back to macos-12.
Additionally, the Linux build now needs Python 3.8, and the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION environment variable enabled to keep using node 16.
Fixes#2028
Github action runners no longer support ubuntu-18.04 hosts and starting
with ubuntu-20.04 our binaries depend on glibc2.30, which is quite
recent. We're switching to building on ubuntu-18.04 containers instead
to not increase requirements.
This is really ugly, but AFAICT:
- omp.h is not a "builtin clang header" in the usual sense, but when
openmp is built it installs to clang's resource dir to be "always
available"
- this makes it into clang packages, e.g. debian's libclang-common-11-dev.
- as a result, if we don't ship it, then <omp.h> can be found by system
clang but not by us.
The only reason to have a separate periodic action was the ability to
run the action "manually" by creating an appropriate release. With the
workflow_dispatch, we can actually trigger the workflow manually with
a convenient UI. Hence, periodic is no longer needed.
gRPC version we use cannot be compiled with libstdc++ that comes with
gcc11 due to a change in transitive dependencies.
This is a temporary fix until we bump the grpc version in a bunch of
deployments.
This allows autoupdate to work in our buggy clients.
See https://github.com/clangd/vscode-clangd/issues/180
Stylistic justification: "clangd_indexing_tools" is one "word" in the
"name-platform-version.zip" naming convention.
That patch added new flags but gRPC is still built with GNU C++
compiler. If we're trying to build both gRPC and LLVM with the same set
of flags, we should enforce additional CMake flags for gRPC.
While building clangd binaries we set required glibc version for symbols
to a minimum to cover systems with older glibc implementations. But we
were not doing that while building gRPC, which might depend on never
versions of these symbols.
Weekly snapshot builds are failing because CMake couldn't find gRPC and
Protobuf libraries. Expanding the path from relative to the full one
solves the problem.
Fixes: https://github.com/clangd/clangd/issues/641
This regressed twice over the last two months (new floating point
function versions, and accidental dynamic linking against zlib).
We also want to avoid regressions when merging remote index.
The test is able to do a little bit more than we use in the automated
build (the --sym flag is unused, as is unversioned --lib=GLIBC) but they're
pretty useful when experimenting with how to fix things!
We run the test right at the end, because if it fails we want to be able
to download the binary artifact and inspect it.
Unfortunately by the nature of the test we can only run it when we
produce a build, so currently weekly.
