Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

😊 Welcome @krinkinmu! This is either your first contribution to the Istio proxy repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

/test all

Does this mean you can finally just run bazel build and it works??? amazing!!

Almost, but there are corner cases. E.g., llvm tools themselves are not built statically, so they still depend on some external libraries, but at the very least installing clang should not be necessary.

And we still need to figure out if we want to go this way or rely on a local toolchain.

/test all

@krinkinmu can you update your PR base on envoyproxy/envoy#42572?

@zirain will do that later today

/test all

Interesting... It works locally, but not on CI. I need to dig a bit more.

/test all

At least it's building now...

@zirain it looks like it builds. I'd need to double check what it's actually building and that the version of GLIBC it needs is indeed 2.28, but on the surface it looks ok.

Aha... I missed something in the configuration apparently - it didn't really use the hermetic sysroot and instead used host GLIBC, which is ok when building insider a container, but not what we actually wanted.

/test all

I tested it locally and it builds using the right sysroot with glibc 2.28

/test all

/test all

Regarding the libncurses library, looking at the clang binary in the hermetic llvm toolchain it's conviniently adds RUNPATH:

readelf -d bin/clang-18

Dynamic section at offset 0x9c03f28 contains 36 entries:
  Tag        Type                         Name/Value
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib] 
...
 0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
...

That means that if we package llvm toolchain with libtinfo.so.5 in the lib directory in the toolchain itself, we should be able to avoid versioning problems. Dynamic linker should search RUNPATH before basically anything else when loading the binary (except for LD_LIBRARY_PATH).

@krinkinmu what's status of this PR?

The PR works on CI and I confirmed that we use 2.28 glibc with this PR. There is one caveat mentioned in the PR description - I can check for options to address that caveat if we agree on the general direction to use hermetic toolchain.

I think using hermetic toolchain is the right direction.
cc @howardjohn @kyessenov WDYT?

Yes, of course, using upstream clang would give you clang 18 and better compilation.

A small update on the issue with libncurses library.

It looks like this is the only weird dependency that causes this problem and LLVM folks said that they removed this dependency in the later version of clang, so say with clang-19 we wouldn't have this problem. However, fixing the latest 18.1.8 release of clang-18 or doing another release (e.g. 18.1.9) is unlikely (LLVM folks made some changes to the process in LLVM 19, so they are not particularly keen on trying to release 18 again).

So two options that make sense to try IMO:

1. We can try to switch to clang-19, but that's obviously a divergence from upstream Envoy, so we should try to do that in upstream Envoy.
2. When building locally and not on CI, just use the non-hermetic toolchain available in the host system.

I think if the option 1 works, it would be the best fix - no divergence, newer compiler, should work the same way on CI and on a local computer.