| 3 Oct 2025 |
 Grimmauld (any/all) | but i accidentially killed the log, oops. Gemme 5min to upload it to termbin again | 10:32:28 |
 Vladimír Čunát | I saw a similar case. And the relevant part seems to be ld complaining about libiberty. | 10:35:21 |
| Grimmauld (any/all) | ye | 10:38:53 |
| Grimmauld (any/all) | libiberty.a, did we kill the static build? | 10:39:14 |
| Grimmauld (any/all) | hmm, no, that bootstrap stage builds libiberty itself instead of pulling the dedicated package | 10:43:03 |
| Vladimír Čunát | 🤷 let's wait which commit the blame falls on. Hopefully it will help. | 10:44:06 |
| Vladimír Čunát | So this one?
411faf46e2c8 gcc: build with --enable-default-pie configure option (#439314)
| 11:22:38 |
| Vladimír Čunát | Reconfirmed breaking nix build -f pkgs/top-level/release.nix stdenvBootstrapTools.x86_64-unknown-linux-gnu.test on this commit and OK on its first parent (the staging branch lineage). | 11:33:49 |
| Grimmauld (any/all) | uh oh | 11:38:32 |
| Grimmauld (any/all) | that is a fat mass-rebuild, so how will we fix it? | 11:39:09 |
| Grimmauld (any/all) | diff --git a/pkgs/stdenv/linux/make-bootstrap-tools.nix b/pkgs/stdenv/linux/make-bootstrap-tools.nix
index 6a1507df734d..c4b204e35837 100644
--- a/pkgs/stdenv/linux/make-bootstrap-tools.nix
+++ b/pkgs/stdenv/linux/make-bootstrap-tools.nix
@@ -50,6 +50,7 @@ rec {
bootGCC = pkgs.gcc.cc.override {
enableLTO = false;
isl = null;
+ enableDefaultPie = false;
};
bootBinutils = pkgs.binutils.bintools.override {
Trying the naive thing rn
| 11:46:11 |
| Grimmauld (any/all) | if this works, then we are done | 11:46:27 |
| Grimmauld (any/all) | if this doesn't work, then emily will have to fix it XD | 11:47:05 |
| Grimmauld (any/all) | HOLY SHIT THAT WORKS | 11:53:51 |
 K900 | Welp | 11:54:11 |
| K900 | Mes when | 11:54:20 |
 Wolfgang Walther | lucky emily, then. | 11:54:25 |
| Grimmauld (any/all) | tbh i have no idea wtf i am doing, but if this works then i won't complain | 11:55:08 |
| Vladimír Čunát | Off the top of my head I'm not sure how many times we roll gcc, i.e. whether the final build (stdenv.cc.cc) will really be PIE enough. But surely better this for now than blocking for long. | 11:56:59 |
| Vladimír Čunát | * Off the top of my head I'm not sure how many times we roll gcc, i.e. whether the final build (stdenv.cc.cc) will really be PIE enough. But surely better this for now than blocking for long. | 11:57:09 |
| K900 | This should not affect the non-bootstrap-tools GCC at least? | 11:57:39 |
| Vladimír Čunát | It shouldn't affect anything practical until we regenerate the bootrap GCC, yes. | 11:58:18 |
| Vladimír Čunát | * It shouldn't affect anything practical until we regenerate the bootstrap GCC, yes. | 11:58:31 |
| K900 | What I'm saying is I don't think we care about the PIE-ness of bootstrap-tools GCC? | 11:58:52 |
| Vladimír Čunát |
It results in a compiler that opportunistically enables pie whenever it does not conflict with other flags.
| 11:59:49 |
| Vladimír Čunát | i.e. it affects things compiled with this GCC. | 11:59:59 |
| Vladimír Čunát | So that's why I was mentioning that I'm not sure how many times we roll things during bootstrapping. Some tools in the final package set are not built by the final GCC, of course. | 12:00:46 |
| Vladimír Čunát | * So that's why I was mentioning that I'm not sure how many times we roll things during bootstrapping. Some stuff in the final package set are not built by the final GCC, of course. | 12:00:53 |
| K900 | Oof | 12:01:01 |
| K900 | OK | 12:01:02 |
