| 20 Dec 2024 |
 Artturin | Was written by John Ericson | 20:32:29 |
 p14 | In reply to @rosscomputerguy:matrix.org
Fun... Having tried to make repro, I now think this was a false alarm | 22:10:53 |
| p14 | In reply to @rosscomputerguy:matrix.org
Fun... * Having tried to make repro, I now think this was a false alarm, apologies. | 22:20:39 |
| 21 Dec 2024 |
|  @stablejoy:matrix.org left the room. | 05:08:14 |
| p14 | reno: (tangent from https://github.com/NixOS/nixpkgs/pull/366401) - it looks funny to me that the llvm sources also have to be built twice, but I have no Darwin experience. I see one build is with the bootstrap tools and one without. I presume that's all expected, but just wonder aloud if there is some way to avoid that. I suppose the reason is that the sources are built by unpacking a FOD and then copying bits out of it, and that copying happens with tools from different stages. And thinking more, I suppose it could be undesirable to reuse the bootstrap -src derivation since it would imply fetching the bootstrap tools if you needed to rebuild the -src derivation. | 11:40:11 |
| p14 | Anyone else wondering what I'm talking about it's these two derivations: (nixpkgs @ )087408a407440892c1b00d80360fd64639b8091d
nix-store --query -R $(nix-instantiate --system aarch64-darwin -A llvmPackages) | grep llvm-src-16 | 11:41:10 |
| p14 | * Anyone else wondering what I'm talking about it's these two derivations: (nixpkgs @ 087408a407440892c1b00d80360fd64639b8091d)
nix-store --query -R $(nix-instantiate --system aarch64-darwin -A llvmPackages) | grep llvm-src-16 | 11:41:16 |
| p14 | * Anyone else wondering what I'm talking about it's these two derivations: (nixpkgs @ 087408a407440892c1b00d80360fd64639b8091d)
nix-store --query -R $(nix-instantiate --system aarch64-darwin -A llvmPackages) | grep llvm-src-16
/nix/store/g0w6vxlsapnd0asv939aj8pdwjbqj2mm-llvm-src-16.0.6.drv
/nix/store/yhzv33cm9bx6sb5i0pvz4s9ikll4sgaj-llvm-src-16.0.6.drv
| 11:41:40 |
 @paparodeo:matrix.org | linux does the same thing I believe. nix-store --query -R $(nix-instantiate -A stdenv) shows xgcc and gcc built and I believe xgcc is the 1st throw away one and gcc is the one used for the stdenv. | 11:55:49 |
| @paparodeo:matrix.org | pkgs/stdenv/linux/default.nix and the darwin one have some comments to why they build twice and matches with your intuition. | 11:59:14 |
 Randy Eckenrode | There are some limitations due to input addressing, but building multiple times during the bootstrap is intentional. The bootstrap is attempting to follow a traditional compiler bootstrap build where the target compiler is used to build itself. | 15:01:15 |
| Randy Eckenrode | * | 15:01:37 |
| Randy Eckenrode | (Limitations like having to use the originally built libc++ instead of building libc++&c with the target compiler.) | 15:01:57 |
| Randy Eckenrode | I would be surprised if that’s what is happening with lldbPlugins unless it’s somehow accidentally capturing a package from the bootstrap that isn’t build otherwise. | 15:03:19 |
| Randy Eckenrode | Ideally, once the bootstrap is finished, everything should be using the same llvmPackages_X version that was built for Darwin. | 15:03:41 |
| Randy Eckenrode | With recent changes, that would include both Rust and cross using the bootstrapped LLVM (which is much better than it used to be). | 15:04:03 |
| * Randy Eckenrode In reply to @reckenrode:matrix.org
I would be surprised if that’s what is happening with lldbPlugins unless it’s somehow accidentally capturing a package from the bootstrap that isn’t build otherwise. looks at the PR | 15:12:27 |
| Randy Eckenrode | Oh, yeah. It’s probably that. The LLVM derivation can be messy like that, capturing (or not) unexpected things. | 15:12:56 |
|  Dimitar joined the room. | 19:47:21 |
| 23 Dec 2024 |
|  @fgrsnau:matrix.org changed their display name from fgrsnau to Stefan. | 23:41:15 |
| 24 Dec 2024 |
 xin | Hi everyone! I encountered this issue today: https://github.com/NixOS/nixpkgs/issues/305858. I also tried ruby.withPackages and got the same result. I'm trying to understand the reason behind this and potentially fix it. Could anyone point me in the right direction or suggest where I should start looking? | 04:36:42 |
| xin | Oh, I guess I should use python3.pythonOnBuildForHost for this purpose? | 05:22:49 |
| xin | I found that several packages are still using python3.withPackages under nativeBuildInputs. Maybe we should do a treewide fix? | 10:22:40 |
| 25 Dec 2024 |
 @genericnerdyusername:matrix.org | How could I get myself a riscv32-unknown-elf gcc? | 21:50:16 |
| @genericnerdyusername:matrix.org | nixpkgs doesnt like it as a crossPlatform | 21:50:37 |
| @genericnerdyusername:matrix.org | to clarify, it should run on x86_64-linux, but produce binaries for riscv | 22:19:29 |
 kuruczgy | riscv32-none-elf works for me, not sure how "unknown" is different from "none" (if this is something bare metal then none should be correct) | 23:14:07 |
| @genericnerdyusername:matrix.org | In reply to @kuruczgy:matrix.org
riscv32-none-elf works for me, not sure how "unknown" is different from "none" (if this is something bare metal then none should be correct) a different program im using expects unknown :/ | 23:15:11 |
| kuruczgy | (Also it's crossSystem not crossPlatform, but hopefully that's just a typo in your message and not your code.) | 23:15:13 |
| kuruczgy | I assume you are getting "error: Unknown kernel: unknown" when you try riscv32-unknown-elf. riscv32-unknown-none-elf does seem to work. What does this "different program" depend on exactly? Expecting crossPlatform to be a particular string sounds quite strange | 23:21:48 |
