| 14 Feb 2025 |
 rosssmyth | I think I see the error | 20:04:26 |
| rosssmyth | * It still errors with infinite recursion. I have it setup as
highPower = with armPkgs;
callPackage ./default.nix {
stdenv =
overrideCC stdenv (buildPackages.wrapCC (stdenv.cc
// {
stdenv.cc.targetPlatform =
stdenv.cc.targetPlatform
// {
gcc =
stdenv.cc.targetPlatform.gcc
// {
arch = "arv6m";
cpu = "cortex-m0";
thumb = true;
};
};
}));
};
| 20:05:06 |
| rosssmyth | No, I don't | 20:06:35 |
 Artturin | Look through the trace | 20:17:09 |
 alexfmpe | In reply to @emilazy:matrix.org
fwiw still personally happy to mentor bringing iOS support up to date in line with my previous statements about how it should work :P I remember, it's just taking longer than I expected to get through pkgsCross.ghcjs so not enough budget yet for iOS | 20:26:24 |
| alexfmpe | There's also the, heh, cross cutting concern of template haskell | 20:27:09 |
| rosssmyth | That still ends up building it in ARM mode. Oh well. | 20:44:36 |
|  lucassong joined the room. | 20:53:29 |
| lucassong | hello | 20:53:47 |
| 15 Feb 2025 |
| alexfmpe | hmm the types.h errors are gone in staging-next, someone must have fixed something in between | 00:45:47 |
| alexfmpe | though android-ndk-toolchain fails from the recent noBrokenSymlinks | 00:46:23 |
| alexfmpe | * though android-ndk-toolchain still fails from the recent noBrokenSymlinks | 00:57:01 |
| alexfmpe | ah yeah no false alarm, I was building the wrong thing, the types.h and other errors are present in staging(-next) | 01:06:05 |
| alexfmpe | fixed this one at least: https://github.com/NixOS/nixpkgs/pull/382182 | 01:23:07 |
|  BenjB83 joined the room. | 10:14:34 |
| BenjB83 changed their display name from BenjamÃn Buske to BenjB83. | 10:43:28 |
| 16 Feb 2025 |
|  KristijanZic joined the room. | 01:07:04 |
|  Jake Hillion joined the room. | 18:26:31 |
| 17 Feb 2025 |
 Axman6 | If you're building on a x86_64-linux system and you build pkgs.pkgsCross.gnu64.foo is there a difference between what it builds and what pkgs.foo? are there any checks that a cross compile isn't actually a cross compile? | 06:11:55 |
| Axman6 | Just wondering if there's anything that checks if buildPlatform and hostPlatform are the same and uses the top level definitions | 06:12:42 |
 K900 | No, there isn't | 07:21:10 |
| alexfmpe | $ nix-build -A hello
/nix/store/p09fxxwkdj69hk4mgddk4r3nassiryzc-hello-2.12.1
$ nix-build -A pkgsCross.gnu64.hello
/nix/store/p09fxxwkdj69hk4mgddk4r3nassiryzc-hello-2.12.1
| 16:06:50 |
| alexfmpe | there are some things that check whether you're doing cross, but not for the purpose of picking a different attribute path | 16:08:28 |
| alexfmpe | I think it's mostly about whether test suites can be run normally, or maybe configuring cross compilers | 16:09:34 |
| alexfmpe | a good deal of cross is just proper build time vs run time separation | 16:09:54 |
| alexfmpe | * I think it's mostly about whether test suites can be run normally, configuring cross compilers, etc | 16:10:24 |
| Axman6 | Cool, looks like that covers all my curiosities. | 23:40:59 |
| 18 Feb 2025 |
|  @mlaga97:matrix.mlaga97.space left the room. | 03:26:00 |
| Axman6 | If, hypothetically, I was insane and wanted to cross compile for windows using pkgsCross.mingwW64, and I wanted to produce statically linked executables, is there any chance what could possibly work? trying pkgs.okgsCross.mingwW64.pkgsStatic.myPackage fails quite quickly, with mingw_w64-headers-static-12.0.0 quite sensibly reporting checking host system type... Invalid configuration 'x86_64-w64-windows-gnu': Kernel 'windows' not known to work with OS 'gnu'. (I assume that pkgsStatic attempts to use musl, which clearly won't work) | 05:30:23 |
| K900 | No can do | 05:34:40 |
