nix compiler shell does not install contemporaneous binutils version

[hanno-becker]

When running in a nix shell for an old toolchain, e.g. ci_gcc48 for gcc-4.8.5, one still falls back to the native binutils, including as. This can lead to confusing results such as the following:

$ (echo "eor3 v0.16b, v1.16b, v2.16b, v3.16b" | gcc -march=armv8.4-a+sha3 -x assembler - -c -o test.o) && echo "SUCCESS" || echo "FAIL"
SUCCESS
$ (echo "int main(void) { return 0; }" | gcc -march=armv8.4-a+sha3 -x c - -c -o test.o) && echo "SUCCESS" || echo "FAIL"
<stdin>:1:0: error: unknown value ‘armv8.4-a+sha3’ for -march
FAIL

Here, gcc -x assembler falls back to as which is actually the host as, which is newer than the gcc installed through nix.

We should consider bundling gcc versions with somewhat contemporaneous binutils versions.

[mkannwischer]

Here, gcc -x assembler falls back to as which is actually the host as, which is newer than the gcc installed through nix.

It's not actually the host as:

% as --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

% nix develop
$ as --version
clang version 19.1.7
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /nix/store/m38zy04q4g42jf6via945wafm4z69m45-clang-19.1.7/bin

That is the default as for the platform

We should consider bundling gcc versions with somewhat contemporaneous binutils versions.

I currently don't see how this can be done conveniently in nix. I'll look into it.

[mkannwischer]

@potsrevennil do you have any thoughts on this?

[potsrevennil]

It's doable to build GCC with a specific Binutils version — as we’ve done that in wrap-gcc in nix/util.nix.

But this doesn't seem to be easy for gcc 4.8, since the Nix 24.05 channel only seems to have Binutils 2.41 and 2.38.

Channel 17.03 has Binutils 2.27, which is still newer than the version we actually need. Pulling from such an old channel doesn’t feel like a good idea, though.

Another way might be to override the Binutils attribute and try building the version we want from scratch — but I’m not sure what kind of issues we might run into with that.

[mkannwischer]

Another way might be to override the Binutils attribute and try building the version we want from scratch — but I’m not sure what kind of issues we might run into with that.

We would have to include this in our cache, I suppose. Otherwise we have to build it on every test.
Even if this works, it would further slow down the building of the cache and blow up the cache size.
The other day it took two hours to build the cache, so I am unsure if we can afford this right now.
Currently out cache size is already more than 5 GiB for the 3 platforms meaning that Github barely lets us keep 2 versions cached. If we increase this more we may run into more cache evictions.

I think we may have to fall back to using pre-built EC2 images instead. That should make it much easier.
@hanno-becker, what do you think about moving the tests for old compilers to EC2? This would also allow us to stop relying on old nix channels which is starting to become messy.

[hanno-becker]

@mkannwischer Would docker not suffice? We should be able to run this on the GH runners, too?

[mkannwischer]

@mkannwischer Would docker not suffice? We should be able to run this on the GH runners, too?

Yes that is a good idea.