| 16 Jun 2025 |
 p14 | That's a good point, so I take that back | 19:44:58 |
| p14 | Fixed. https://github.com/NixOS/nixpkgs/pull/417354 Tristan Ross | 20:52:19 |
 Tristan Ross | In reply to @p14:matrix.org
Fixed. https://github.com/NixOS/nixpkgs/pull/417354 Tristan Ross Seems more like a workaround | 20:59:27 |
| Tristan Ross | What if a package wants libgcc_s and is static? | 20:59:43 |
| p14 | libgcc_s => the s in libgcc is shared | 20:59:57 |
| p14 | https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html | 21:00:19 |
| 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 |
| 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 |
