refactor: toolchain into multiple bldr packages

[smira]

There's one version bump: binutils is 2.33.1 as 2.31.1 had some bug
reading compressed object data, not sure how it wasn't triggered before.

Overview:

• Alpine toolchain is used to build stage1 (bootstrap) binutils
  and gcc -> /boostrap
• bootstrap musl is built (just to make programs compile) -> /bootstrap
• bootstrap libstdcxx is built -> /bootstrap
• musl is built -> /toolchain
• binutils are built -> /toolchain
• gcc is built -> /toolchain
• linux-headers are built -> /toolchain
• everything /toolchain is combined together

Signed-off-by: Andrey Smirnov [email protected]

[smira]

wip, as I want to do a bit more testing before I consider it safe

[smira]

I got these exposed top-level to avoid duplication between multiple packages using same sources, and so that we can't forget to bump all of them

[andrewrynhard]

I'm just curious, what was the reason for dropping the --target flag?

[smira]

I'm just curious, what was the reason for dropping the --target flag?

I think it's not needed, because there's no way toolchain stages can be mixed now:

1. Alpine toolchain is used only to boostrap gcc & binutils, after that it's gone (we copy only /bootstrap tree at that phase)
2. Once we build stage2 toolchain, boostrap toolchain goes away, once again via finalize: with /toolchain only.

--target is not a big deal, but we have to export all these export AS=${TARGET}-as while there's no other as in the path when we're building.

LFS does that, as both compilers are in the path as I understand (host and stage1), while for us it's not an issue

[andrewrynhard]

I'm just curious, what was the reason for dropping the --target flag?

I think it's not needed, because there's no way toolchain stages can be mixed now:

1. Alpine toolchain is used only to boostrap gcc & binutils, after that it's gone (we copy only /bootstrap tree at that phase)
2. Once we build stage2 toolchain, boostrap toolchain goes away, once again via finalize: with /toolchain only.

--target is not a big deal, but we have to export all these export AS=${TARGET}-as while there's no other as in the path when we're building.

LFS does that, as both compilers are in the path as I understand (host and stage1), while for us it's not an issue

SGTM.

[smira]

wip, as I want to do a bit more testing before I consider it safe

tested locally with tools/ and pkgs/, feels safe enough

[smira]

Pushed small update to remove security.insecure from Makefile (copy-paste from main talos repo).

[andrewrynhard]

We don't need --addr, buildkit will respect BUILDKIT_HOST env var, but we can clean this up later.