!ayCRiZriCVtuCUpeLp:nixos.org

Nix Cross Compiling

575 Members
126 Servers

Load older messages

SenderMessageTime
1 Jan 2026
@sielicki:matrix.orgsielickiI 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:xlumurb.eusymphorienno because your hook is built when building cmake17:51:00
@symphorien:xlumurb.eusymphorienso 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 targetPlaform17:52:02
@sielicki:matrix.orgsielickiI 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 outputs17:53:31
@sielicki:matrix.orgsielickiregardless of whether I'm doing that atm in this repo17:53:52
@symphorien:xlumurb.eusymphorienwhen 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-defined17:54:28
@symphorien:xlumurb.eusymphorienthen how do you plan for each derivation to choose the correct toolchain.cmake ?17:55:20
@qyliss:fairydust.spaceAlyssa RossYou will find a lot of agreement on this.17:58:21
@qyliss:fairydust.spaceAlyssa RossWe've moved away from implicit hooks for newer build systems17:58:31
@qyliss:fairydust.spaceAlyssa 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:matrix.orgsielicki 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:matrix.orgsielickithanks all for the input, I'll play around a bit more with this18:03:16
@xokdvium:matrix.orgSergei 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 nixpkgs18:03:17
@xokdvium:matrix.orgSergei Zimmerman (xokdvium) It would be nice if the hooks were bound to the stdenv and were memorised accordingly 18:03:51
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)* It would be nice if the hooks were bound to the stdenv and were memoised accordingly18:04:04
@zimward:zimward.moezimwardcan 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:matrix.orgArtturin
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:matrix.orgArtturinReproducer?18:55:07
@zimward:zimward.moezimward 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:defenestrate.itmatthewcroughan changed their display name from matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) to matthewcroughan.19:54:37
@artturin:matrix.orgArtturinhttps://github.com/NixOS/nixpkgs/blob/700a15863ef33cc39478ac9a2ae5a92b3f4ad25e/pkgs/by-name/ne/newlib/package.nix#L39-L4820:17:17
@artturin:matrix.orgArtturin gcc is always the for build gcc 20:25:07
@artturin:matrix.orgArtturinIt doesn't exist when cross-compiling without buildPackages.stdenv.cc in depsBuildBuild20:25:29
@debtquity:matrix.orgdebtquity joined the room.20:54:59
2 Jan 2026
@icurtis:matrix.org@icurtis:matrix.org left the room.20:26:41
5 Jan 2026
@bake.monorail:matrix.orgbake.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:matrix.orgbake.monorail Thanks <3 I'm so happy :) 17:49:19
9 Jan 2026
@alexfmpe:matrix.orgalexfmpe 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:matrix.orgalexfmpe * 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
@opna2608:matrix.orgPunathe compiler defines them based on the selected/configured target12:12:39

Show newer messages

Back to Room ListRoom Version: 6