On the toolchain current status

Hi All,

Most of you are aware that our toolchain is currently outdated. We always had very few people
working on it through the years and I took over once Barth left, because it was needed.

However, I have been having very little time to work on Arch related stuff lately and the
toolchain is the most noticeable victim, given it is one of the most time consuming.
In this meantime, a few things also happened that compounded to the issue, among them, we enabled LTO.

Right now I’m working on bringing new glibc 2.35 and also waiting on binutils release so we
can bring the toolchain up to date. I’m aware we also have a GCC release coming out soon, and
the toolchain will need a new rebuild then.

For the future, we are trying to bring more people to work with the whole toolchain, so it is
not too much of a bus factor. We should have at least two toolchain maintainers, not just one.

I hope this serves to assuage the concerns over the current status of our toolchain, both present
and going future.

Giancarlo Razzolini

Good news.


he was possibly forced to break the months-long silence due to this article:


There has been a lot of noise recently, not just that one article.

It’s unfortunate, as the toolchain is a critical part of the distro, so it’s important that it is correct. This also means it takes a significant amount of time and effort, and maintainer time is limited.

Gian is making inroads, but it’s slow going, especially because the packages need to aim to be reproducible too - yet another layer of complexity to solve.

As an illustration, try building the glibc package now. I almost guarantee it won’t build for you the first time you try.


yeah, and I most likely won’t be able to solve those, but that’s also why I am not a maintainer :wink:

of course, but that’s something that fortunately he also sees:

this however falls into the same category of problems I also saw with Arch a while back:

Arch seems to have an essential problem with manpower and geographical distribution of said manpower (that falls under risk-management).
Also, they seem to not communicate that adequatly, it only surfaces when packages are delayed.


and it starts to flow:
gcc: https://archlinux.org/packages/staging/x86_64/gcc/

glibc: https://archlinux.org/packages/staging/x86_64/glibc/

binutils: https://archlinux.org/packages/staging/x86_64/binutils/

1 Like

Bit sad that nobody downstream seems to want to contribute either (ie Valve is using an Arch base for their SteamDeck).

It is up to volunteers to donate their time for this considerable ongoing task.

Wait for it. Valve are sending Decks to a number of Arch maintainers, they have a vested interest in making Arch work well.

1 Like

Great, now they’ll have even less spare time.


Looking at the new PKGBUILD changes at least there seems to a larger pool of people contributing to this.


Anyone testing watch out for this:

It will prevent initramfs from being generated, which in turn will prevent you from booting. Workarounds are straightforward until a fixed mkinitcpio is pushed out.

i think thats now fixed:

1 Like

Now on core glibc 2.35-2