| 19 May 2025 |
 emily | if you can actually make having only pkgsOnBuild and pkgsOnHost and nothing else work correctly then I will be eternally grateful | 13:43:22 |
| emily | it'll also make GCC uglier and more annoying, which will be a great argument for switching to LLVM | 13:43:48 |
 K900 | No, pkgsTargetTarget is [host = target, target = target] | 13:46:26 |
| K900 | And in our current world host == target for packages that don't have target | 13:46:53 |
| emily | yes but we're talking about build = | 13:47:24 |
| emily | oh | 13:47:30 |
| emily | sorry I misread the package set you were talking about | 13:47:34 |
| emily | then I'm confused, isn't this just pkgsBuildTarget | 13:47:49 |
| emily | which we use a fair bit | 13:48:02 |
| K900 | Yes but it doesn't exist on Canadian cross | 13:48:26 |
| emily | I mean, it can, right? you just have to build another compiler | 13:49:48 |
| K900 | Well yes but that kinda defeats the point of Canadian cross | 13:51:02 |
| emily | is there a point of Canadian cross? | 13:52:30 |
| K900 | Yes, the point of Canadian cross is that you use your slow build machine to build a cross-compiler for a fast host machine | 13:53:19 |
| K900 | And then use that cross-compiler to build packages for target | 13:53:27 |
| K900 | But faster | 13:53:31 |
| emily | you could just build the compiler on the fast host machine. | 13:55:33 |
| emily | to me the sensible use-case for Canadian cross looks like "we can only get x86 CI, not AArch64, but we want to offer AArch64 binaries of our compiler for various targets" | 13:56:23 |
| emily | in which case building an extra compiler is basically fine. | 13:56:32 |
| 21 May 2025 |
|  WeetHet changed their profile picture. | 10:59:09 |
| 22 May 2025 |
 rhelmot | perl modules cross is an irredeemable nightmare | 22:29:14 |
| rhelmot | I cannot figure out how to get it to build extension modules that do not link the build platform's libc... | 22:30:16 |
| rhelmot | new problem - https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/misc/gdb/default.nix#L40 I don't think this is correct, since when I build gdb with buildPlatform = linux and hostPlatform = freebsd, this ends up being a linux path pulling glibc into the closure, which is completely useless. | 22:56:58 |
| rhelmot | does anyone know how to test whatever that line is supposed to support? | 22:57:41 |
| rhelmot | https://github.com/NixOS/nixpkgs/pull/73574 concerning... | 23:03:10 |
| 23 May 2025 |
 @trofi:matrix.org | I thin it should auto-load .py gdb script for target libstdc++ when yoiu load c++ based programs to debug | 14:53:59 |
| @trofi:matrix.org | /nix/store/7c0v0kbrrdc2cqgisi78jdqxn73n3401-gcc-14.2.1.20250322-lib/lib/libstdc++.so.6.0.33-gdb.py | 14:55:05 |
| @trofi:matrix.org | And given that it does not work on gdb gdb I think it is missing /lib subdir. | 14:59:06 |
| 24 May 2025 |
|  fromtheeast710 joined the room. | 05:09:22 |
|  neobrain joined the room. | 14:01:33 |
