| 17 Aug 2021 |
piegames | I need a riscv-gcc but with a different arch. The best I got so far is (in an overlay):
pkgsCross = super.pkgsCross // {
# Our platform requires to set the gcc.arch
riscv32-embedded = import <nixpkgs> (super.config // {
crossSystem = {
config = "riscv32-none-elf";
libc = "newlib";
gcc.arch = "rv32im";
};
});
};
| 13:04:12 |
piegames | It works, but I need a second nixpkgs import. Is there a way around that? | 13:04:35 |
sterni (he/him) | it's not possible as pkgsCross uses nixpkgsFun which is then nixpkgs self import partially applied, but it is only accessible internally unfortunately | 13:08:57 |
sterni (he/him) | but in essence pkgsCross also internally just reimports nixpkgs, so there's not much difference | 13:09:14 |
sterni (he/him) | I guess you should use super.path instead of <nixpkgs> though to make this more protable | 13:09:30 |
sterni (he/him) | * I guess you should use super.path instead of <nixpkgs> though to make this more portable | 13:09:35 |
piegames | In reply to @sternenseemann:systemli.org I guess you should use super.path instead of <nixpkgs> though to make this more portable That sounds great. Actually my problem is not the double import, but having to pass a pinned nixpkgs down to the overlay | 13:10:43 |
sterni (he/him) | yeah self.path should fix that | 13:11:05 |
sterni (he/him) | is probably a bit cleaner, but would be the same anyways | 13:11:14 |
piegames | Thank you | 13:12:21 |
piegames | Also, can I build a gcc that supports multiple arch targets? (I found hints that this ought to be possible) And if so, how would I chose between them at build time? | 13:27:27 |
John Ericson | sterni (he/him): https://lore.kernel.org/linux-kbuild/20210303230708.l6pbk5o5nc2qa5of@google.com/ I look forward to us making an analogous change! | 18:30:49 |
John Ericson | Once the gcc-ng stuff is done | 18:30:57 |
Mic92 | Ericson2314: what is gcc-ng? | 18:37:28 |
John Ericson | Mic92: https://github.com/NixOS/nixpkgs/pull/132343 | 18:38:11 |
John Ericson | group effort | 18:38:15 |
Mic92 | Ericson2314: to avoid building gcc when trying to build libgcc when cross compiling? | 18:39:10 |
John Ericson | Mic92: well avoid building gcc twice cross stage static vs cross stage final | 18:39:48 |
John Ericson | do what we do with llvm | 18:39:53 |
Mic92 | got it | 18:40:01 |
John Ericson | then we can massively cleanup cc-wrapper L:) | 18:40:55 |
John Ericson | * then we can massively cleanup cc-wrapper :) | 18:40:57 |
sterni (he/him) | John Ericson: hmmm, we'll have rt libs via -L then? or does clang treat the gcc rt libs specially always? | 21:45:10 |
sterni (he/him) | I'm guessing it's gonna end up being a symlinked resource root again? | 21:45:32 |
John Ericson | If -L doesn't work for anything -B should | 21:45:43 |
sterni (he/him) | ah yeah right | 21:47:32 |
| 18 Aug 2021 |
| Piper McCorkle (she/her or they/them) changed their display name from Piper McCorkle to Piper McCorkle (she/her or they/them). | 07:12:42 |
| siraben (he/him) changed their display name from siraben to siraben (he/him). | 19:37:16 |
| 19 Aug 2021 |
Mic92 | Alyssa Ross: Hi. In my current project I am building a tool that can spawn processes and block devices in hypervisor using ptrace: https://github.com/Mic92/vmsh My current prototype works on qemu, and I am currently looking into crosvm. I am wondering if crosvm uses multiple processes rather than threads? | 07:09:45 |
| Yuka (she/her) changed their display name from Yuka to Yuka (she/her). | 07:11:06 |