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

▲

lokar 3 days ago | parent | next [-]

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

▲

jeffbee 3 days ago | parent | prev | next [-]

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.

▲

steeve 2 days ago | parent | prev | next [-]

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

▲

prpl 3 days ago | parent | prev | next [-]

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

▲

jmmv 3 days ago | parent | prev | next [-]

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

▲

steeve 2 days ago | parent | next [-]

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

▲

lokar 3 days ago | parent | prev [-]

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

▲

jmmv 3 days ago | parent [-]

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

▲

lokar 3 days ago | parent | next [-]

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.

▲

jmmv 3 days ago | parent | next [-]

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.

	▲	lokar 3 days ago \| parent [-]
		Yeah, ideally you could build your toolchain from source on any platform. But, in some cases that’s not possible

▲

remexre 3 days ago | parent | prev [-]

Does that result in working NSS?

	▲	lokar 3 days ago \| parent [-]
		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.

▲

throwaway2046 2 days ago | parent | prev | next [-]

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

▲

prpl 3 days ago | parent | prev [-]

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

▲

paulddraper 3 days ago | parent | prev [-]

Agreed.