Wasi P2 is different enough to Wasi P1 to warrant being treated entirely
separately, rather than as two minor variants of the same thing. P3 will
likewise want to be a different target.
I've left aliases in place; maybe eventually, those can be deprecated
and removed. I've tested this, but it's possible there might be breakage
somewhere (e.g., the canonical doubles for P1 have changed, though I
can't imagine why anyone would rely on that).
Fixes https://github.com/NixOS/nixpkgs/issues/435954
Versions before 144 vendor bindgen 0.69, which emits invalid Rust for
libc++ 21's attributed basic_string::__self_view alias on Darwin.
This was exposed by commit 0758fc3add ("darwin.libcxx:
20.1.0+apple-sdk-26.0 -> 21.1.6+apple-sdk-26.4"), where libc++
changed `basic_string::__self_view` from a typedef to an attributed
`using` alias. bindgen then drops the alias template parameter and emits
`basic_string___self_view = ...<_CharT>`.
The solution is to blocklist the unused `string_view` internals for the
profiler Rust API. They are not used in the actual build.
Note: Mozilla 144 updated vendored bindgen via:
https://bugzilla.mozilla.org/show_bug.cgi?id=1985509
Assisted-by: Codex gpt-5.5 xhigh
Mozilla vendors various patches on top of ICU that upstream is very slow
to accept. Instead of extracting the patches and keeping them up to date
on our system icu we decided it would likely be fine to rely on the
vendored version.
this creates some eval errors that will be fixed in the next commit
done with the following script:
```fish
\#!/usr/bin/env fish
set packagesjson (nix eval --impure --json --expr '
let
lib = import ./lib;
in
import pkgs/servers/x11/xorg/default.nix (lib.mapAttrs (
name: _:
if name == "lib" then
lib
else if name == "config" then
{ allowAliases = false; }
else
name
) (__functionArgs (import pkgs/servers/x11/xorg/default.nix))) { }
' | jq)
set one (grep '^ [A-Za-z0-9_-]*$' pkgs/servers/x11/xorg/default.nix | string trim | string replace -r '$' Z | sort | string sub -e -1)
set two (grep '^ [A-Za-z0-9_-]* = [A-Za-z0-9_-]*;$' pkgs/servers/x11/xorg/default.nix | cut -d= -f1 | string trim | string replace -r '$' Z | sort | string sub -e -1)
for arg in $one $two
set oname $arg
set nname (echo $packagesjson | jq -r .$oname)
if test $nname = null
echo (set_color red)warn:(set_color normal) unknown package xorg.$oname >&2
continue
end
echo $oname "->" $nname
# replace basic xorg.$name references
for file in (rg -F "xorg.$oname" --files-with-matches pkgs)
# special cases
sd -F "$oname = xorg.$oname;" "$nname = $nname;" $file
# replace
sd -F "xorg.$oname" "$nname" $file
# fixup function arguments
# prevent duplicate function args
if grep -E " ($oname|$nname),\$" $file >/dev/null
continue
end
if grep 'xorg\..' $file >/dev/null # case1: there is more so we can't just remove the function arg
if grep ' xorg,$' $file >/dev/null
sd ' xorg,$' " xorg,
$nname," $file
else if grep ' xorg ? .*,$' $file >/dev/null
sd 'xorg( ? .*),$' "xorg\$1,
$nname," $file
else
sd -F 'xorg,' "$nname,
xorg," $file
end
else # case there is no more xorg..* so we can just replace the function arg
sd 'xorg(| ? .*),.*$' "$nname," $file
end
end
end
nix fmt
```
With lto enabled for darwin, we now observe timeouts in Hydra [1]. Looks
like the default timeout is ~4h, and usually builds succeeds in a few
hours, so 1d should be more than enough to complete a build, even with
heavy node load.
[1] https://hydra.nixos.org/build/319560484
mesa looks at the name of the executable / argv0 to determine which
quirks it should apply.
Example: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38845
By setting argv0 to .${binaryName}-wrapped instead of ${binaryName},
these do not apply.
I'm not sure what the "Needed to find Mozilla runtime" comment was
supposed to mean, but I can confirm dropping this line
(which is equivalent to `--argv0 "$out/bin/${binaryName}`
fixes the issue.
Firefox seems to run properly, with `about:support` reporting AGX
G13/G14 as intended by the mesa quirk, when running on an Asahi MacBook.
Fixes#476721.
There's a bug in llvm 21 that makes Firefox crash on loading a PNG
favicon that is being investigated in Mozilla bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1995582
While this is being fixed, switch to llvmPackages_20 for aarch64-darwin.
(x86_64-darwin is not affected.)
Note: this change will also affect Thunderbird. Though strictly speaking
not a required change because we are not aware of a specific issue with
Thunderbird (yet), I feel we may want to stick to the same LLVM for both
types of Mozilla apps while this is being investigated. It also
simplifies the code somewhat.
Fixes#453372
Recent firefox started using fileport.h API. This API was exposed in SDK
15.4, but we are still running on 15.2. XNU source headers contain the
header for some time, so we can pull it from there instead.
