As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

#29500

Hey Joshua, thanks for jumping on this so quick!

This change does not fix the build in the case I was hitting (which is the default configuration in the devcontainer). Namely: clang-14 with libstdc++-9.

I'm fairly ignorant about compilers/stdlibs, but is the GCC/clang differentiation important here, or is it just a requirement of the libraries having the correct function/template defined? As I mentioned in the other PR comment, this works with clang-14 and libstdc++-11

Thanks for the heads up. What exactly is the 'devcontainer'? Is that this: https://github.com/envoyproxy/envoy/blob/main/.devcontainer/README.md ?

Are libstd++ versions supposed to match clang versions? What works best for me is to download the version of clang that matches what's used in Envoy CI, 14.06, which is found at https://github.com/llvm/llvm-project/releases/tag/llvmorg-14.0.6 . That includes a library (libclang.so.14.0.0). Why would you use a compiler of one version with a library from a different version?

Yeah, that is the one. It seems pretty loosely supported, but it hasn't completely languished. I had been using vim with VERY spotty LSP for several months. After recently looking at #27680 I gave up and switched to vscode+devcontainer, which has been working pretty much flawlessly.

That said though, the documentation in bazel/README.md instructs users to download llvm, run bazel/setup_clang.sh to set up the clang.bazelrc, then add --config=clang to user.bazelrc to make it default. Just below that, it indicates that --config=clang means clang with libstdc++, while you have to use --config=libc++ to get clang with libc++. That's corroborated by the relevant sections in .bazelrc

I really don't have any practical or ideological preference here, just following what documentation/issue resolution I've been able to find has led me to this sorta Frankenstein's monster of a toolchain setup that purports to be the best practice for Envoy dev. I'm happy to be instructed otherwise and help update the documentation!

Thanks for testing this @jbohanon -- can you see if this latest version compiles for you?

Thanks @jbohanon !