| 16 Jun 2025 |
 p14 |
GCC provides a low-level runtime library, libgcc.a or libgcc_s.so.1 on some platforms.
| 21:00:28 |
| p14 | * libgcc_s => the s in libgcc_s is shared | 21:01:15 |
 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 |
