Compiller mismatch, bootstrap is leaking into stdenv

gytis-ivaskevicius commented 3 years ago

I believe this is a tech debt issue. ~~Would like to get some sort of confirmation that it is or the reasoning behind it.~~

Summary:

Glibc and other GCC dependencies are compiled using GCC8 (from bootstrap-tools)

Few commands to play around:

$ objdump -s --section .comment $(nix eval nixpkgs#stdenv.cc.libc.outPath --raw)/lib/ld-linux-x86-64.so.2
nix-repl> removeAttrs stdenv.cc.libc.stdenv.cc ["type"]

~~#### Quick fix:~~ ~~Update bootstrap-tools~~

Proper fix:

Add additional stdenv stage to recompile gcc - something along the lines: X -> Y -> final package set The final package set has GCC from stage Y, GCC deps from stage X, no earlier stages may leak in. Stage X is supposed to be a stage4 or something very similar to it

~~I could easily prepare PR for "Quick fix" - but probably there is no point in doing so since it is too big of a change to be merged to 21.05. Right?~~

FRidh commented 3 years ago

cc @vcunat

vcunat commented 3 years ago

I can't see any problem in here. Things I see and don't think they're issues:

some parts are compiled by older GCC 8 from bootstrap, notably our glibc
some packages record version of the compiler that was used on them (glibc as you pointed out)

Bootstrapping tools have inherent trust complications, so it makes sense not to update them too often. In our case it's also technically a little more complicated than other changes.

gytis-ivaskevicius commented 3 years ago

There are several libraries that are compiled using GCC8 - off the top of my head its gmp, mpfr, mpc, glibc (possibly more)

Issues that I see:

No GCC 10 compiler optimization improvements (Other dependencies besides glibc are not exposed externally. As for Glibc - of course, it is used everywhere and I guess one my say that it is a performance-critical package)
Compiler compatibility. As far as I am aware currently there are no issues with it, but it really makes me wonder what would it take for such issues to appear. :thinking:

Stdenv design

And yes, I agree about the trust of bootstrap. But can we also agree that an additional stage should be added at some point? Also, do you guys think that this is more of an RFC material kind of issue? Or not big enough?

From my perspective:

We trust bootstrap-tools that it will produce binaries that generate correct output (gcc) - but nixpkgs needs an additional stage to make sure that output is correctly optimized as well (gcc/glibc).

vcunat commented 3 years ago

But can we also agree that an additional stage should be added at some point?

Maybe, but overall I'm not (yet) convinced that they are significant advantages. And there's some price to pay as well, depending on the way we'd lengthen the bootstrapping process (rewriting libc dependency in gcc wouldn't be nice, so yet another gcc build and thus slowing future stdenv changes like glibc security patches).

Ericson2314 commented 3 years ago

https://github.com/NixOS/nixpkgs/pull/132343 I hope could help with these sorts of things. We will have much more control over how the GCC runtime libs are bootstrapped, so wee can rebuild libraries if need be without rebuilding the compiler itself.

stale[bot] commented 2 years ago

I marked this as stale due to inactivity. → More info

ajs124 commented 2 years ago

still an issue -.-

NixOS / nixpkgs