| 16 Jun 2025 |
 Tristan Ross | Hmm, I'll have to take a look more after work. | 21:03:59 |
 p14 | I think I see what you're saying; that you want to have a way to implement fake libgcc for static builds. I feel uncertain about the wisdom of that -- I guess the use case is for build systems that try to explicitly link it? In our case, since we're already a stdenv.hostPlatform.useLLVM, I would have thought libgcc should be irrelevant, since it should be the compiler deciding whether to link it. | 21:05:06 |
| p14 | Tristan Ross: I've added a bit more thinking to https://github.com/NixOS/nixpkgs/pull/417354#discussion_r2150897655 -- heading out shortly in case you want a quick last roundtrip for tonight. | 21:12:43 |
| 17 Jun 2025 |
 emily | libgcc_s has symbols that are in compiler-rt, not just libunwind | 06:14:48 |
| emily | it will be especially easy to observe breakage with e.g. binary packages | 06:14:57 |
| emily | but really glibc in general makes assumptions about this | 06:15:11 |
| emily | I think stuff like the hack in rustc is also downstream of this and that it would just-work with llvm-libgcc | 06:15:36 |
| emily | we could just assemble our own libgcc_s if the build logic in llvm-libgcc doesn't work for us though | 06:17:47 |
| emily | but I'd be surprised… at least their version script generating machinery should be very useful for it | 06:18:24 |
 Grimmauld (any/all) | We also need to still do the 64 bit time thingy for 32 bit systems, i got stuck when i tried | 07:38:31 |
 K900 | Ugh I forgor | 08:03:35 |
| K900 | And probably ino64 too | 08:03:41 |
| emily | it requires ino64, so yeah | 08:05:38 |
| emily | I'm still a bit worried about old binary games | 08:05:57 |
| K900 | You know what is cool actually | 08:14:22 |
| K900 | We already have all the tools to make an ino32 environment for those | 08:14:39 |
| Grimmauld (any/all) | In reply to @emilazy:matrix.org
I'm still a bit worried about old binary games Eh it'll be fine - less SDL1 garbage the SDL team ends up maintaining on the side! (Yes this is a selfish consideration...) | 08:15:18 |
| K900 | I mean source built games can be patched | 08:17:02 |
| K900 | It's the binaries that are worrying | 08:17:08 |
| K900 | But like, we have the tools | 08:17:15 |
| K900 | We can always use the tools | 08:17:19 |
| emily | which doesn't solve the problem of wanting to get off time32 + ino32 so things stop breaking :) | 08:31:44 |
| emily | however I think it's probably true that old binary games are not super likely to work patchelfed to use our stuff anyway for the most part | 08:31:58 |
| K900 | Well we can only maintain the things we need | 08:32:00 |
| emily | I'd mainly worry about SDL1 | 08:32:07 |
| emily | sure, yeah. but that's already the state of i686-linux | 08:32:18 |
| emily | anyway I dunno it's probably fine. worth trying at least | 08:32:23 |
| emily | I don't know how many people are actually patchelfing 1999-era games to use Nixpkgs libraries to begin with. | 08:32:41 |
| K900 | In reply to @emilazy:matrix.org
sure, yeah. but that's already the state of i686-linux Yes, but ino32 probably covers a lot less than like, all of Mesa oh wait fuck shit | 08:34:00 |
| K900 | Yeah ok | 08:34:16 |
