This fixes:
Could not load ICU data. UErrorCode: 2
We're using a hook instead of a wrapper because various things like to
reference the unwrapped dotnet executable.
This was achieved using the following command:
sd 'wrapGAppsHook\b' wrapGAppsHook3 (rg -l 'wrapGAppsHook\b')
And then manually reverted the following changes:
- alias in top-level.nix
- function name in wrap-gapps-hook.sh
- comment in postFixup of at-spi2-core
- comment in gtk4
- comment in preFixup of 1password-gui/linux.nix
- comment in postFixup of qgis/unwrapped-ltr.nix and qgis/unwrapped.nix
- comment in postFixup of telegram-desktop
- comment in postFixup of fwupd
- buildCommand of mongodb-compass
- postFixup of xflux-gui
- comment in a patch in kdePackages.kde-gtk-config and plasma5Packages.kde-gtk-config
- description of programs.sway.wrapperFeatures.gtk NixOS option (manual rebuild)
Since the tool is exposed more prominently now, we should clear up what
it is and note that it is to be considered unstable, i.e. we may change
it if the necessity arises. (In practice it is probably going to be
fairly stable though, as compiler interfaces tend to be quite stable.)
Should we add a version?
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.
To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
We don't need to artificially make sure that we can execute the wrapper
scripts on the build platform by using stdenv's shell (which comes from
buildPackages) since our cross infrastructure will get us the wrapper
from buildPackages. The upside of this change is that cross-compiled
wrappers (e.g. pkgsCross.aarch64-multiplatform.gcc) will actually work
when executed!
For bootstrapping this is also not a problem, since we have a long
build->build platform chain so runtimeShell is just as good as
stdenvNoCC.shell. We do fall back to old ways, though, by explicitly
using the bootstrap-tools shell in stage2, so the adjacent bash is only
used from stage4 onwards. This is unnecessary in principle (I'll try
removing this hack in the future), but ensures this change causes zero
rebuilds.
To reduce dependencies (mainly nix-prefetch-git and through that git,
git-lfs) when we just need to fixup a lock file, eg when building electron.
This also tries to avoid needless rebuilds when eg. golang is updated.
Also this cleans up and combined the build/installPhase of both tools to
be a lot simpler.
In delicate code like this, it seems unwise to pass something of as
something it isn't for convenience's (?) sake. It causes a slight
possibility for confusion with `buildPackages.stdenv`. However, it
should be possible to eliminate the need for this in a separate change.
`stdenv.is*` defaults to `hostPlatform` which is technically incorrect
here, since what we are gating concerns the target platform only.
This would be a problem in practice if cross compiling from
x86_64-darwin to aarch64-darwin whilst using gcc which is probably
rare enough.
