Nixpkgs Stdenv | 228 Members | |
| 74 Servers |
| Sender | Message | Time |
|---|---|---|
| 25 Nov 2024 | ||
* g++ uses libstdc++.so as part of it's implementation. libstdc++ uses g++ to build itself. It's not directly related to the seed. Even after you got the seed you need to build both of those. You need to build both in a single derivation to get them linked against one another (gcc usually builds it in 2 stages internally to untagle from builder's gcc/libstdc++.so, which nixpkgs disables and suffers afterwards, fresh example is https://github.com/NixOS/nixpkgs/issues/342904). | 21:47:55 | |
| Isn't this kind of problem exactly why the Guix bootstrap involves multiple versions of GCC? Obviously, you want to build as few versions as possible and it seems like someone else has already done the hard work of finding a usable path from stage0 to modern GCC. I suppose the main difficulty is porting the build steps to Nix? | 21:58:52 | |
| that has already been done | 21:59:24 | |
| it doesn't address trofi's concern, which comes up within a GCC build | 21:59:30 | |
| Right, I see now. Nix needs a DAG but it requires hacking into the GCC build system to untangle libstdc++ from g++. | 22:00:54 | |
Yeah, or patching built binaries after the fact to redirect to fresher libstdc++. | 22:23:26 | |
| 26 Nov 2024 | ||
| 07:49:11 | ||
| 27 Nov 2024 | ||
In reply to @trofi:matrix.orgI think it is still related | 06:34:27 | |
| Nix wants a dag, but the from-scratch bootstrap forces a dag | 06:34:38 | |
| in practice, reality does dictate it's a dag | 06:34:47 | |
| the way the world get around that in practice is bootstrapping to a fixed point | 06:35:02 | |
| * the way the world get around that in practice is bootstrapping to a fixed point, either byte-for-byte or just the ABI | 06:35:20 | |
In reply to @philiptaron:matrix.orgGood list! Would like to we the GCC repackaging on that list too :) | 06:35:57 | |
| what repackaging? | 06:36:33 | |
In reply to @Ericson2314:matrix.orgIt's a DAG from build step standpoint. But from installation directory standpoint gcc's own bootstrap allows installing libstdc++ and gcc multiple times to make sure both are using one another. nix does not allow for in place file updates and one has to resort to file copies from one store path into another and requires binary patching to achieve the same effect (which is fragile for self-references and effectively requires CA compatibility as a precondition). | 06:56:31 | |
Luckily gcc is CA-compatible, but glibc is not. As a result I have to use hacks like https://bpa.st/raw/5QWA just to make glibc work in CA (and in cases when I have to rewrite references to relocate glibc) :) | 07:02:13 | |
__FILE__ has been a persistent painful cause of "trivial" self-references / unwanted references for me lately | 07:08:30 | |
| not even with CA derivations | 07:08:33 | |
| At least macro expansion should be worked around by https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/gcc/patches/13/mangle-NIX_STORE-in-__FILE__.patch | 10:50:46 | |
| emily: I was working on a branch with Philip Taron (UTC-8) that builds GCC in parts like we do with LLVM | 15:03:08 | |
| we are both pressed for time, but I very much want to see it done, as it cuts down on rebuilds and makes cross sane | 15:03:26 | |
| 18:17:59 | ||
| I see | 19:10:12 | |
fwiw we probably need to un-split some LLVM stuff since some of it is pretty broken. e.g. Clang having separate lib output breaks unwrapped compilers | 19:10:38 | |
| 28 Nov 2024 | ||
| 18:48:46 | ||
| 18:50:23 | ||
| 1 Dec 2024 | ||
| 00:08:07 | ||
| 10 Dec 2024 | ||
| https://crab.fit/nixpkgs-stdenv-team-meeting-699727 made a crab fit thing to find the availability of everyone so we can work on our updates to give to the SC. | 05:33:42 | |
| Minor quality of life improvements:
| 09:12:53 | |
| 11 Dec 2024 | ||
| 14:19:13 | ||