| 16 Jun 2025 |
 emily | the libgcc_s thing is broken and should be removed anyway | 18:38:44 |
| emily | since it's not using llvm-libgcc | 18:38:55 |
| emily | there's lots of workarounds in the tree because of that | 18:39:14 |
 p14 | can't we just dontCheckForBrokenSymlinks = true 🫣 | 18:40:48 |
| emily | btw, does pkgsStatic.pkgsLLVM even stack right? | 18:42:15 |
| p14 | I believe it did until recently. | 18:48:53 |
| p14 | Module this issue and any issues uncovered after fixing it. | 18:49:23 |
 Tristan Ross | In reply to @emilazy:matrix.org
since it's not using llvm-libgcc llvm-libgcc isn't really possible the last time I tried it, it'd take a lot just to make it work. | 19:10:23 |
| Tristan Ross | In reply to @p14:matrix.org
can't we just dontCheckForBrokenSymlinks = true 🫣 No, because it's referring to a shared library instead of a static one | 19:12:05 |
| Tristan Ross | Which is why I mentioned that the library extension thing should be used from platform. | 19:12:37 |
| emily | well, linking libgcc_s to not libgcc_s also doesn't work :) | 19:16:55 |
| Tristan Ross | I've not seen it not work | 19:26:26 |
| Tristan Ross | So so far, it works enough to have a working basic desktop NixOS config on a Pi 4 | 19:26:50 |
| p14 | So, what's the minimal set of actions we can take to reinstate it? I guess it would need a pass through staging at least. | 19:31:00 |
 Alyssa Ross | Should be 0 rebuilds outside static | 19:44:45 |
| 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 |
