| 15 Aug 2021 |
 @jbg:matrix.org | it's not specific to glib, either — put just about anything in buildInputs and it will fail to build, since all the standard headers are missing | 08:45:14 |
 symphorien | ah, sorry. There is a bug where clang-7 works but not clang or the other way around, and I thought that was an instance of it | 08:47:54 |
| @jbg:matrix.org | ah right. the iphone64 cross system is supposed to use Xcode's prebuilt clang; you have to manually download Xcode.app and add it to the store before it will work. so it's clang 11 or 12 or whatever is being shipped by Xcode these days. that part seems to be working fine, but it just doesn't seem to set up the sysroots or whatever properly | 08:49:40 |
| @jbg:matrix.org | aarch64-apple-ios-clang seems to be a shell script that adds the needed arguments pointing to paths in the nix store, but it's not clear to me which part of that is not working correctly | 08:50:44 |
| 17 Aug 2021 |
|  Yuki (they/them) joined the room. | 02:47:59 |
 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 | 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 | but in essence pkgsCross also internally just reimports nixpkgs, so there's not much difference | 13:09:14 |
| sterni | I guess you should use super.path instead of <nixpkgs> though to make this more protable | 13:09:30 |
| sterni | * 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 | yeah self.path should fix that | 13:11:05 |
| sterni | 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 | 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 | 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 |
