| 1 Jan 2026 |
 symphorien | * | 17:48:01 |
 sielicki | my thought is that any given stdenv, regardless of whether it's exposed as pkgs.stdenv or pkgs.pkgsCross.foobar.stdenv, has buildPlatform and hostPlatform. buildPlatform is where it's building, hostPlatform is where it will run, and targetPlatform is just a notion for the antiquated gcc-ism where a compiler runs on buildPlatform but can only produce code for targetPlatform. | 17:49:26 |
| sielicki | I don't think that applies here, though. If stdenv.cc is set correctly, it encodes targetPlatform. cmake still only cares about buildPlatform and hostPlatform. No? | 17:50:22 |
| symphorien | no because your hook is built when building cmake | 17:51:00 |
| symphorien | so cmake is interested in the plaform where cmake will be executed (which will then be the build plaform, but when building the hook is the hostPlaform) and the targetPlaform | 17:52:02 |
| sielicki | I don't think the hook ought to be built when building cmake. That's kind of the point, the same cmake binary can be used with many different toolchain.cmake outputs | 17:53:31 |
| sielicki | regardless of whether I'm doing that atm in this repo | 17:53:52 |
| symphorien | when building pkgsCross.aarch64-multiplatform.opencv on x86_64, cmake and your hook are called with and stdenv with build=host=x86_64 and target=aarch64 whereas opencv is called with a stdenv with build=x86_64 and host=aarch64 and target is ill-defined | 17:54:28 |
| symphorien | then how do you plan for each derivation to choose the correct toolchain.cmake ? | 17:55:20 |
 Alyssa Ross | You will find a lot of agreement on this. | 17:58:21 |
| Alyssa Ross | We've moved away from implicit hooks for newer build systems | 17:58:31 |
| Alyssa Ross | In favour of having an e.g. cmakeBuildHook that does all the automatic stuff, and which can be built separately. | 17:59:16 |
| sielicki | symphorien: I don't think we even need to write the toolchain to the nix store as a derivation. I'm kind of spitballing here, but I guess this could just be a pure nix string handled by the existing lib.systems.parse code | 18:00:35 |
| sielicki | thanks all for the input, I'll play around a bit more with this | 18:03:16 |
 Sergei Zimmerman (xokdvium) | Speaking of the current cmake situation, the system where cmakeFlags and mesonFlags are constructed in make-derivation has quite big overhead. makeCMakeFlags and makeMesonFlags are one of the hotter functions in the whole of nixpkgs | 18:03:17 |
| Sergei Zimmerman (xokdvium) | It would be nice if the hooks were bound to the stdenv and were memorised accordingly | 18:03:51 |
| Sergei Zimmerman (xokdvium) | * It would be nice if the hooks were bound to the stdenv and were memoised accordingly | 18:04:04 |
 zimward | can someone explain to me why i get a gcc that targets x86_64-linux in a derivation from a stdenv that has riscv32-none-elf as its target? | 18:06:22 |
 Artturin | In reply to @zimward:zimward.moe
can someone explain to me why i get a gcc that targets x86_64-linux in a derivation from a stdenv that has riscv32-none-elf as its target? $CC is that? | 18:55:02 |
| Artturin | Reproducer? | 18:55:07 |
| zimward | like nix develop nixpkgs#legacyPackages.x86_64-linux.pkgsCross.riscv32-embedded.newlib-nano
> gcc --verbose
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=/nix/store/kzq78n13l8w24jn8bx4djj79k5j717f1-gcc-14.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/kzq78n13l8w24jn8bx4djj79k5j717f1-gcc-14.3.0/libexec/gcc/x86_64-unknown-linux-gnu/14.3.0/lto-wrapper
Ziel: x86_64-unknown-linux-gnu
Konfiguriert mit: ../gcc-14.3.0/configure --prefix=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gcc-14.3.0 --with-gmp-include=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gmp-6.3.0-dev/include --with-gmp-lib=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gmp-6.3.0/lib --with-mpfr-include=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-mpfr-4.2.2-dev/include --with-mpfr-lib=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-mpfr-4.2.2/lib --with-mpc=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libmpc-1.3.1 --with-native-system-header-dir=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.40-66-dev/include --with-build-sysroot=/ --with-gxx-include-dir=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gcc-14.3.0/include/c++/14.3.0/ --program-prefix= --enable-lto --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin --disable-libcc1 --with-isl=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-isl-0.20 --disable-bootstrap --enable-default-pie --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Thread-Modell: posix
Unterstützte LTO-Kompressionsalgorithmen: zlib
gcc-Version 14.3.0 (GCC)
there is also the correct gcc in there with the target triplet prefix (and is set as the CC, but when i add cflags it tries to use the incorrect gcc) | 19:01:33 |
|  matthewcroughan changed their display name from matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) to matthewcroughan. | 19:54:37 |
| Artturin | https://github.com/NixOS/nixpkgs/blob/700a15863ef33cc39478ac9a2ae5a92b3f4ad25e/pkgs/by-name/ne/newlib/package.nix#L39-L48 | 20:17:17 |
| Artturin | gcc is always the for build gcc | 20:25:07 |
| Artturin | It doesn't exist when cross-compiling without buildPackages.stdenv.cc in depsBuildBuild | 20:25:29 |
|  debtquity joined the room. | 20:54:59 |
| 2 Jan 2026 |
|  @icurtis:matrix.org left the room. | 20:26:41 |
| 5 Jan 2026 |
 bake.monorail | Alyssa Ross: any chance you can take another look to #458935? John Ericson made some other suggestions that have been implemented. | 10:50:27 |
| 6 Jan 2026 |
| bake.monorail | Thanks <3 I'm so happy :) | 17:49:19 |
| 9 Jan 2026 |
 alexfmpe | where do platform symbols like loongarch come from?
I hit symbol issues in libffi when trying to build cross-compiling GHC on several platforms
For instance, I'm getting https://github.com/libffi/libffi/blob/2263d6037f8ef6b8d5bef14117ad1a17c32a20b9/src/loongarch64/ffitarget.h#L66
which should mean __loongarch64 isn't defined, but loongarch is or the error on line 39 would trigger first
I see both of them in https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html but don't know where they're supposed to come from | 12:07:45 |
