| 1 Jan 2026 |
 symphorien | and introducing new ones is not a light decision | 17:46:53 |
| symphorien | (if I undersant Alyssa Ross correctly) | 17:47:24 |
| symphorien | if the terminolofy about platforms is unclear I can try to explain more | 17:47:53 |
| 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 |
