rustc 1.73.0 introduced a new x86_64-unikraft-linux-musl target. This
triple is a bit of a lie — the kernel in this case is unikraft, which
isn't Linux, it just tries to be compatible with it. But this
User-Agent-like string of a triple now exists, and with it comes some
fallout.
Spidermonkey asks rustc for the list of supported targets, then picks
the one that best matches the GNU triple it's building for, which in
the native case config.guess will say is x86_64-pc-linux-musl. Prior
to rustc 1.73.0, all was well, because there was only one x86_64 musl
triple, but now there are two: x86_64-unknown-linux-musl, and
x86_64-unikraft-linux-musl, and neither of those are obviously closer
than the other to x86_64-pc-linux-musl to Spidermonkey's build system.
As a result, it can't decide which target to pass to rustc, and bails
out.
We can fix this by telling Spidermonkey what platform it should be
building for, rather than letting it guess, which previously we did
only when cross compiling. This approach is already used in the
Firefox derivation (which is why it was not affected by the rustc
update), so it's been well tested already.
Closes: https://github.com/NixOS/nixpkgs/pull/266560
Closes: https://github.com/NixOS/nixpkgs/pull/282923
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Because the configure script hasn't been update to work with Python 3.10
and never will. Spidermonkey 78 is EOL.
Traceback (most recent call last):
File "/build/firefox-78.15.0/obj/../js/src/../../configure.py", line 25, in <module>
from mozbuild.configure import (
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/configure/__init__.py", line 33, in <module>
from mozbuild.util import (
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/util.py", line 760, in <module>
class HierarchicalStringList(object):
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/util.py", line 785, in HierarchicalStringList
class StringListAdaptor(collections.Sequence):
AttributeError: module 'collections' has no attribute 'Sequence'
Split the argument list into build and runtime dependencies and sort
everything alphabetically.
Unpin icu, it works with icu70, which is the latest version at this
time.
Remove yasm, it's not needed in firefox either.
Spidermonkey depends on rustc, so we have the best chance at only
having a single LLVM in the build closure if we use the same LLVM that
rustc depends on.
cc-rs is hardcoded to use the soft-float ABI for riscv64, while
the rest of the system is double-float. This is not just a missing
stub header file - You can't link object files using different
ABIs.
The configurePlatforms mkDerivation parameter needs to be an empty list
to avoid bogus defaults from breaking cross compilation.
Document the parameter to prevent it from being cleaned up.
The use of unspliced llvmPackages in configureFlags was causing an
eval failure when cross-compiling, but since later versions of
Firefox/Spidermonkey can correctly detect clang and libclang without
those arguments being specified, we can just backport that
patch (which applies cleanly), and not have to worry about it any
more.
