Hacker News Reader

Comment by fooblaster | Hacker News Reader

Why ain't the first answer.. use a bazel provided tool chain instead of using system toolchains? This article is totally mad.

View on HN

Yeah, making the entire tool chain hermetic and versioned is one of the main benefits of bazel.

You can have every developer cross-compile from a different os/cpu platform

You make it sound simple. Bazel's docs are minimal and what exists is often wrong. For a C or C++ toolchain you might turn to a contributing project such as toolchains_llvm, but even those experts are still figuring it out, and they give you little guidance on how to assemble your sysroot, which is the actual issue in the article. And, the upstream distributions of LLVM are built under certain assumptions, so unless you know exactly what you are doing, you probably also want to build LLVM instead of using their archives. If you figure out how to build LLVM in a completely consistent and correct way with respect to the STL and support libraries, you will be perhaps the 3rd or 4th person in history to achieve it.

Yes: https://github.com/cerisier/toolchains_llvm_bootstrapped

llvm_toolchain or gcc-toolchain or the uber one are all some possibilities

Because those Bazel toolchains don’t come with a glibc? How could they?

What? Of course they can, how is that hard?

You need that glibc on the target system, and glibc doesn’t like static linking. How do you ship the built binary?

You include the target glibc as part of your toolchain

And, I always prefer to actually pick my glibc independently from the host os and ship it with the binary (generally in an OCI image). This way you can patch/update the host without breaking the service.

Does that result in working NSS?

I normally statically link as much as possible and avoid nss, but you can make that work as well, just include it along with glibc.

Right, so you need to end up creating a container to package the glibc with the binary. Which is not very different from having sysroots.

But what about any tools compiled from source and used during the build? Those can also suffer from these issues.

Yeah, ideally you could build your toolchain from source on any platform. But, in some cases that’s not possible

no, you just need a compatible starlit/glibc. you pick an old version (e.g. RHEL8) or otherwise compile with multiple tool chains if you need newer glibc features

Is musl not an option? It's best to avoid glibc altogether if possible.

This one does, we use it with great success: https://github.com/cerisier/toolchains_llvm_bootstrapped

Agreed.

Reply on news.ycombinator.com