| 25 Dec 2024 |
 @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 |
| @genericnerdyusername:matrix.org | im trying to get riscof to work, and it asks for a specific gcc toolchain | 23:22:41 |
| @genericnerdyusername:matrix.org | i could replace all uses of unknown with none, but im already out of my depth, i dont want to add more points of failure | 23:23:08 |
| kuruczgy | Ah I see, it hardcodes the riscv32-unknown-elf prefix everywhere. Nixpkgs will always include the kernel name in the prefix, so you cannot have it without none: https://github.com/NixOS/nixpkgs/blob/444c1e08d4fc93dd5a53ff052397d2d2b26dfe7a/lib/systems/parse.nix#L542 | 23:38:29 |
| kuruczgy | You probably want to define some aliases somehow. (Or just search&replace in the whole source in patchPhase -unknown-elf with -unknown-none-elf | 23:39:31 |
| kuruczgy | * You probably want to define some aliases somehow. (Or just search&replace in the whole source in something like patchPhase -unknown-elf with -unknown-none-elf) | 23:39:52 |
| 26 Dec 2024 |
|  @10leej:matrix.org joined the room. | 01:41:00 |
| @10leej:matrix.org left the room. | 01:41:51 |
|  elikoga changed their display name from elikoga to elikoga (@38c3 📞448{0,1}. | 15:21:53 |
| elikoga changed their display name from elikoga (@38c3 📞448{0,1} to elikoga (@38c3 📞448{0,1}). | 15:26:06 |
| elikoga changed their display name from elikoga (@38c3 📞448{0,1}) to elikoga (@38c3 📞488{0,1}). | 15:26:48 |
| 27 Dec 2024 |
 rhelmot | I opened https://github.com/rust-lang/rust/issues/134811 against rustc while trying to debug https://github.com/NixOS/nixpkgs/pull/356769 if anyone here wants to save the rust people some pain | 00:53:53 |
|  raitobezarius changed their display name from raitobezarius to raitobezarius (DECT: 3538 / EPVPN 2681). | 07:32:31 |
|  Dimitar set a profile picture. | 11:41:03 |
| Dimitar changed their display name from dimitarnestorov to Dimitar. | 11:42:12 |
|  A2 changed their display name from A2 to A2 (☎️ 61777). | 15:25:27 |
| 29 Dec 2024 |
| elikoga changed their display name from elikoga (@38c3 📞488{0,1}) to elikoga (@38c3 📞488{0,1,9}). | 11:03:18 |
|  DavHau joined the room. | 14:29:44 |
| DavHau | I think I discovered a fundamental issue with rust cross compilation in nixpkgs and I could use some help finding a solution.
I was wondering why python bcrypt would build binaries for the build platform instead if the host platform and found out that cargoSetupHook (and all other rust hooks as well) behave differently when used inside mkDerivation vs in buildRustPackage.
This issue affects many packages in nixpkgs, and I would like to fix the root cause instead of working around it.
The reason is that buildRustPackage consumes the non-spliced hooks via this inherit statement, and therefore them being put inside nativeBuildInputs there doesn't have the usual effect as it has in all other package builder functions.
Most rust hooks have been designed with the wrong build/host/target triples in mind, and once used inside mkDerivaiton or buildPythonPackage this results in stuff being built for the wrong platform.
I was about to add proper splicing to those hooks and refactor most of them, but I'm questioning this approach now.
Why even have splicing for hooks, as they should only ever be used inside nativeBuildInputs and nowhere else.
Would it make more sense to disable splicing for these hooks somehow in all places, instead of refactoring them?
If yes, how would I best implement disabling the splicing? There doesn't seem to be such feature.
| 14:53:33 |
| DavHau | * I think I discovered a fundamental issue with rust cross compilation in nixpkgs and I could use some help finding a solution.
I was wondering why python bcrypt would build binaries for the build platform instead of the host platform and found out that cargoSetupHook (and all other rust hooks as well) behave differently when used inside mkDerivation vs in buildRustPackage.
This issue affects many packages in nixpkgs, and I would like to fix the root cause instead of working around it.
The reason is that buildRustPackage consumes the non-spliced hooks via this inherit statement, and therefore them being put inside nativeBuildInputs there doesn't have the usual effect as it has in all other package builder functions.
Most rust hooks have been designed with the wrong build/host/target triples in mind, and once used inside mkDerivaiton or buildPythonPackage this results in stuff being built for the wrong platform.
I was about to add proper splicing to those hooks and refactor most of them, but I'm questioning this approach now.
Why even have splicing for hooks, as they should only ever be used inside nativeBuildInputs and nowhere else.
Would it make more sense to disable splicing for these hooks somehow in all places, instead of refactoring them?
If yes, how would I best implement disabling the splicing? There doesn't seem to be such feature.
| 14:53:53 |
 emily | "Why even have splicing for hooks, as they should only ever be used inside nativeBuildInputs and nowhere else." seems wrong | 14:54:56 |
| emily | you might need to build a Rust program for the build platform in a derivation | 14:55:09 |
| emily | in which case it should go in depsBuildBuild | 14:55:15 |
| emily | (indeed this is normal to do via build.rs etc., but you can imagine e.g. Linux building a Rust tool among its other build-platform tools as a non-top-level-Cargo-driven example) | 14:55:54 |
| DavHau | OK thanks, then I guess I start refactoring | 15:11:16 |
| emily | if you can fix the setEnv nonsense that binds a tool chain way too early that would be great :p | 15:28:18 |
| DavHau | Maybe setEnv turns out to be one of many workarounds that have been implemented just because the splicing was not applied correctly in all places. | 15:37:46 |
| emily | thanks for taking this on 💜 | 15:38:18 |
