Build failure: pkgsCross.aarch64-multiplatform.qt5.qtsvg

[Artturin]

$ nix build ".#pkgsCross.aarch64-multiplatform.qt5.qtsvg"
this derivation will be built:
  /nix/store/mri8dvgmwgjqa1ism4c4c818z8nmxn5s-qtsvg-aarch64-unknown-linux-gnu-5.15.11.drv
building '/nix/store/mri8dvgmwgjqa1ism4c4c818z8nmxn5s-qtsvg-aarch64-unknown-linux-gnu-5.15.11.drv'...
qtsvg-aarch64-unknown-linux-gnu> Error: detected mismatched Qt dependencies:
qtsvg-aarch64-unknown-linux-gnu>     /nix/store/g287i30g2x5qdssmlcifz0g4xhkygpil-qtbase-aarch64-unknown-linux-gnu-5.15.11-dev
qtsvg-aarch64-unknown-linux-gnu>     /nix/store/pgdx2hvksknbfyvkflx0ii43cixsmvqz-qtbase-5.15.11-dev

$ nix why-depends ".#pkgsCross.aarch64-multiplatform.qt5.qtsvg" "/nix/store/g287i30g2x5qdssmlcifz0g4xhkygpil-qtbase-aarch64-unknown-linux-gnu-5.15.11-dev" --derivation
/nix/store/mri8dvgmwgjqa1ism4c4c818z8nmxn5s-qtsvg-aarch64-unknown-linux-gnu-5.15.11.drv
└───/nix/store/h8iwi8ivg7x7vfdsignyvfqpzag8rczs-qtbase-aarch64-unknown-linux-gnu-5.15.11.drv
$ nix why-depends ".#pkgsCross.aarch64-multiplatform.qt5.qtsvg" "/nix/store/pgdx2hvksknbfyvkflx0ii43cixsmvqz-qtbase-5.15.11-dev" --derivation
/nix/store/mri8dvgmwgjqa1ism4c4c818z8nmxn5s-qtsvg-aarch64-unknown-linux-gnu-5.15.11.drv
└───/nix/store/cpgfl1mw4hikicab2ibrham4jwzxxiqj-qmake-hook.drv
    └───/nix/store/3gbpk26qabcr0938n1kss22y7164s1q5-qtbase-5.15.11.drv

[Artturin]

Checking out one commit before #264903 shows that it's not the cause, the error is a bit different though

qttranslations> Error: detected mismatched Qt dependencies:
qttranslations>     /nix/store/9j2lnzf3r4z6dkn961p1vxgbiw1acvh3-qtbase-5.15.10-dev
qttranslations>     /nix/store/rclswi560p3z8451679iqcmhirx1krs6-qtbase-5.15.10-dev

[Artturin]

Caused by 68cc025

@alyssais reported the issue in the pr #246022 (comment)

@K900

Will be fixed by the qtbase-setup-hook change in 6399762
It should be possible to backport that change, but the other changes sadly will cause breakage in packages which have strictDeps enabled

CC @amjoseph-nixpkgs

[andrewbaxter]

6399762 looks like it may be gone, but I think it was a part of #264964

[ghost]

Yeah, I've seen this too and I have a bunch of messy hacks in my local tree to work around it.

I am really burned out on QT cross compiling stuff. I need to not think about it for a few weeks. It's really draining.

[eryngion]

Well, I have to say that the strict check in qtbase-setup-hook is still a good litmus test. depsTargetTargetPropagated member (qtbase) of a nativeBuildInputs dependency (qmake) should be a hostTarget, not a buildHost package like in #269756 (comment)

The problem here is in stdenv.buildPlatform == stdenv.hostPlatform check in qmake. It should go something like this:

  # qmake is a nativeBuildInput, and will be shifted back in cross-compilation chain
  # so we need to shift this check forward to compensate
  isCrossBuild = stdenv.hostPlatform != stdenv.targetPlatform;

(A shameless plug of #267311 from where this snippet will hopefully be gone soon.)

[eryngion]

depsTargetTargetPropagated member (qtbase) of a nativeBuildInputs dependency (qmake) should be a hostTarget

Which will probably pull qmake-the-binary out of the PATH and also break the build.

Another piece of the puzzle is pyqt-builder that determines the target platform by contents of QMAKE_XSPEC string that is compiled into qmake-the-binary. Doesn't seem to be a big deal if we're doing Linux to Linux or Darwin to Darwin, but it can matter if we're targeting Android or iOS.

UPD: And I'm completely forgetting that qmake-the-binary itself relies on this baked-in XSPEC. So we can't really use the binary from buildHost package without modifications to setup hooks.

So maybe the right solution for mixed-arch packages is to force a hostTarget version of qtbase into propagatedBuildInputs of qmake-the-package and nativeBuildInputs of some other packages?

UPD: Ah, yeah, we're already doing this, but in qtModule instead of qmake, so it really works only inside the walled garden of qt5.
https://github.com/NixOS/nixpkgs/pull/264965/files#r1382497243
https://github.com/NixOS/nixpkgs/pull/264965/files#r1382503226

[eryngion]

So maybe the right solution for mixed-arch packages is to force a hostTarget version of qtbase into propagatedBuildInputs of qmake-the-package and nativeBuildInputs of some other packages?

And if somebody uses overrideScope on qt5 and changes qtbase we will again get two versions of it in one build because in makeScopeWithSplicing' only pkgsHostTarget get the news. It will even build in most cases if we're accurate to propagate the old version only for the sake of qmake-the-binary. So we'll still need to relax the check in qtbase-setup-hook or move qmake&co to a separate output.

UPD: Except that I can't find a way to get the proper version of qtbase from qmake-the-package point of view, that is targetTarget, to shove it explicitly into propagatedBuildInputs . So echo $dev >> $dev/nix-support/propagated-native-build-inputs it is. It even works.

[RossComputerGuy]

I've noticed the same thing when cross compiling Steam on aarch64-linux with pkgsCross.gnu64.