| 1 Jan 2026 |
 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 |
| 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:08:15 |
 Puna | the compiler defines them based on the selected/configured target | 12:12:39 |
| Puna | https://github.com/gcc-mirror/gcc/blob/9a2402ad31db7507cb63905a8d98ce81769d9835/gcc/config/loongarch/loongarch-c.cc#L50-L56 | 12:13:18 |
| alexfmpe | so in this case GHC? or the c compiler? | 12:13:19 |
| Puna | well, whichever compiler is processing that file ig | 12:13:45 |
| alexfmpe | hmm the actual failing command seems to be gcc | 12:15:39 |
| alexfmpe | oh wait a second it does hit the line 39 error | 12:37:06 |
| alexfmpe | both errors show up actually | 12:37:19 |
| alexfmpe | so maybe ghc isn't configuring gcc properly for loongarch? | 12:37:33 |
