Change:
sha256 = "sha256-vUhP71vZ5XFG7MDkPFpAcCUL4kIdzHJ1hAkwqIi6ksQ="; }; <del> # We have no LTO on i686 since commit 22284b0 postPatch = lib.optionalString stdenv.isi686 '' substituteInPlace chelper/__init__.py  --replace "-flto -fwhole-program " "" ''; </del> sourceRoot = "source/klippy"; # there is currently an attempt at moving it to Python 3, but it will remain

Discussion:
efibootmgr fails to compile from i686 to armv6l (raspberryPi), because is false and is passed in CFLAGS, however the gcc cross-compiler doesn't support the flag. Steps to reproduce the behavior: x86-64 Linux, The build to complete successfully. Changing the efibootmgr derivation to use instead of fixes the build but I'm not sure this is the right fix. It seems that the derivation is perhaps right, and gcc should support LTO on i686 for non-i686 target platforms. Perhaps the references in the gcc sections of pkgs/top-level/all- should read ? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --efibootmgr doesn't have any maintainers listed and I think the actual problem relates to gcc. Please run and paste the result. Maintainer information:
It looks like LTO availability depends on this setting: So immediately I have a few thoughts: We should consolidate these definitions and make them available via e.g. gcc.passthru so that packages can check whether they are allowed to use LTO in a non ad-hoc way Your buildPlatform modification appears to be correct, as the enableLTO setting depends on gcc's hostPlatform rather than its targetPlatform
I agree that that's the effect, but is that the intent? Is LTO a problem on i686 hosts or i686 targets, or both? It looks like this was first introduced in by who might have some additional context for the change.
Good point, usually settings like that affect the target platform. It's possible this was only tested for the native case, so it's a good idea to verify the platform predicate is correct.
It was reaction to non-cross problems during bootstrapping. It's well possible that they won't appear when not bootstrapping (e.g. any cross). Confirming that gcc builds should be enough for the problems from my commit.
I see. It sounds like maybe switching on is more appropriate, then. I'm a bit new to Nix, is there a way to force a build from scratch rather than a fetch from cache? The docs are failing me here.

I think you want
Linking likely related so I don't forget to look into it along with this
Sorry, maybe I merged it too soon :sweat_smile: ?
No no worries, I didn't link it there because I don't think the supportsLTO ~ isi686 cleanup is your responsibility. There are probably other locations as well I'll need to look into.
Hmm, so I was thinking I'd figure out the right host/target platform distinction for gcc and then expose whether it has LTO with e.g. . But I'm unable to encounter any scenario where LTO doesn't work on i686, so I think we can reenable it fully, and I'll just remove the treewide i686-specific LTO workarounds if that sounds reasonable.
efivar LTO seems broken for an unrelated reason (it's broken on x86_64 too), everything else seems to work fine with LTO on i686 (regardless of native or cross compilation). PR coming soon.