| 10 Aug 2021 |
 sterni | although I could try just setting int64_t there or int32_t depending on platform.bits | 21:03:31 |
| sterni | okay I'd need to find out how big long long is in any case | 21:07:31 |
| sterni | also stuff like ECL_STACK_DIR seems ominous | 21:07:38 |
| 15 Aug 2021 |
|  @jbg:matrix.org joined the room. | 04:41:03 |
| @jbg:matrix.org | i'm trying to cross-compile some packages for aarch64-apple-ios. my host system is aarch64-apple-darwin20.6.0 | 04:41:35 |
| @jbg:matrix.org | i have this shell.nix:
let pkgs = import <nixpkgs> {
crossSystem = (import <nixpkgs/lib>).systems.examples.iphone64;
};
in
pkgs.callPackage (
{mkShell, pkg-config, glib}:
mkShell {
nativeBuildInputs = [
pkg-config
];
buildInputs = [
# glib
];
}
) {}
| 04:42:05 |
| @jbg:matrix.org | this works, and there is a aarch64-apple-ios-clang inside the shell, but it doesn't seem functional (it cannot find stdarg.h or other standard headers) | 04:42:50 |
| @jbg:matrix.org | if i uncomment glib (a package that i would like to cross compile), the build fails with
In file included from /nix/store/mkhms56d0nl4mx3553nncqjn9k7l8vqc-libSystem-prebuilt/include/stddef.h:69:
/nix/store/mkhms56d0nl4mx3553nncqjn9k7l8vqc-libSystem-prebuilt/include/sys/_types/_ptrdiff_t.h:32:28: error: 'long type-name' is invalid
| 04:44:28 |
| @jbg:matrix.org | other packages fail with different errors, but mostly always related to standard headers | 04:44:48 |
|  shantaelihu joined the room. | 06:47:09 |
| shantaelihu removed their display name shantaelihu. | 06:48:07 |
| shantaelihu | 06:48:38 |
| shantaelihu left the room. | 06:51:13 |
 symphorien | In reply to @jbg:matrix.org
this works, and there is a aarch64-apple-ios-clang inside the shell, but it doesn't seem functional (it cannot find stdarg.h or other standard headers) you should use $CC, this way there is no doubt about what to use | 08:24:10 |
| @jbg:matrix.org | yes, i'm using $CC (which is aarch64-apple-ios-clang) — the problem is that the wrapper doesn't seem to be providing all needed args for it to find system headers | 08:43:16 |
| @jbg:matrix.org | would be interested whether someone with x86_64-darwin host system can reproduce it (just take the above shell.nix and uncomment glib in buildInputs). if it works on x86_64-darwin then i guess it's an issue with aarch64-darwin host | 08:44:26 |
| @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 |
