| 18 Dec 2025 |
 bake.monorail | thanks, I will take a look, that's what I was looking for | 13:49:00 |
 emily | in some ways it is ideal: you get a less patched compiler that is closer to the old version you actually want, with versions of its dependencies closer to what it actually expected at the time | 13:52:37 |
| emily | retro X tends to go a lot better with retro Y | 13:52:44 |
| emily | (which is why another side effect of packaging old versions is that you end up with the exponential cost of carrying old versions of entire dependency trees all the way) | 13:53:06 |
| bake.monorail | yeah but importing nixpkgs multiple times is Sad™ | 13:53:37 |
| emily | well, then just import one? :) | 13:54:05 |
| emily | (mixing a compiler from one version with packages from another isn't a great idea anyway) | 13:54:17 |
| bake.monorail | stuck in 2021 forever | 13:54:18 |
| emily | well, yes… if the premise is using a compiler from 2021, that's the life you've chosen :) | 13:54:38 |
| bake.monorail | eh, it's more complicated than that, but OK | 13:54:57 |
| bake.monorail | more on practical things, I assume you're somehow involved in maintaing compilers, what would you think about making compilers more externally overridable (I'm thinking about making versions an argument of pkgs/development/compilers/gcc/all.nix. I guess it wouldn't be too bad, what do think? | 13:56:57 |
| bake.monorail | * more on practical things, I assume you're somehow involved in maintaing compilers, what would you think about making compilers more externally overridable (I'm thinking about making versions an argument of pkgs/development/compilers/gcc/all.nix. I guess it wouldn't be too bad, what do you think? | 13:57:01 |
| bake.monorail | * more on practical things, I assume you're somehow involved in maintaing compilers, what would you think about making compilers more externally overridable. I'm thinking about making versions an argument of pkgs/development/compilers/gcc/all.nix. I guess it wouldn't be too bad, what do you think? | 13:57:16 |
| emily | wouldn't really do much good | 14:01:13 |
| emily | the GCC derivations have pretty extensive version conditionals | 14:01:20 |
| emily | the LLVM ones are closer to being something you can reasonably override versions out-of-tree but still not really there | 14:01:35 |
| emily | I suggest just maintaining a fork of gcc/ | 14:01:45 |
| emily | it will be less painful than a nest of hacky overrideAttrs | 14:02:00 |
| emily | (I also suggest putting this effort into making a newer GCC work instead) | 14:02:15 |
| bake.monorail | OK, thanks for the feedback | 14:02:29 |
 @rosssmyth:matrix.org | Something I was considering yesterday:
Currently we have gcc-arm-embedded, which is a pre-built GCC distribution. It has a manifest with all the configure flags. How hard is it to add a new version of GCC? I took a little look and there's a lot of machinery all over the place in the GCC directory. Maybe easier to use the NG package set?
| 15:22:17 |
 K900 | Add a new version of GCC that does what? | 15:23:37 |
| K900 | Builds a proper nixpkgs stdenv/ | 15:23:50 |
| K900 | * Builds a proper nixpkgs stdenv? | 15:23:51 |
| K900 | Because gcc-arm-embedded is extremely not that | 15:23:57 |
| emily | gcc-arm-embedded is basically just there because we don't have working stdenvs for its targets, I think. | 15:32:21 |
| 3 Apr 2026 |
|  Charles joined the room. | 20:48:10 |
| 18 Dec 2025 |
| @rosssmyth:matrix.org | yes | 15:34:15 |
| 3 Apr 2026 |
| Charles | so i'm looking at building relibc with nixpkgs out-of-tree, and i have it successfully building for x86_64 linux now (no idea if it works though lol). now i'm trying to get cross to x86_64 redox going, but when i do that, i get infinite recursion:
error:
… while evaluating an expression to select 'drvPath' on it
at «internal»:1:552:
… while evaluating strict
at «internal»:1:552:
(stack trace truncated; use '--show-trace' to show the full trace)
error: infinite recursion encountered
note: trace involved the following derivations:
derivation 'relibc-static-x86_64-unknown-redox-rolling'
derivation 'x86_64-unknown-redox-gcc-wrapper-15.2.0'
derivation 'x86_64-unknown-redox-binutils-wrapper-2.44'
i know that redox has its own binutils implementation(s?) so i'm guessing i need to package and use that to break the cycle?
| 21:00:06 |
| 18 Dec 2025 |
| @rosssmyth:matrix.org | Nixpkg's cross-compilation infra doesn't really work with some targets | 15:34:38 |
