Windows: nix-store-tests cannot be cross-compiled — unity build exceeds the COFF section limit

[awsmadi]

nix-store-tests cannot be cross-compiled for x86_64-w64-mingw32 at all. The unity build
concatenates the suite into a single translation unit whose object file exceeds the section count
the COFF assembler will accept.

$ nix build .#nix-store-tests-x86_64-w64-mingw32
...
[1/2] Compiling C++ object nix-store-tests.exe.p/meson-generated_nix-store-tests-unity0.cpp.obj
FAILED: [code=1] nix-store-tests.exe.p/meson-generated_nix-store-tests-unity0.cpp.obj
x86_64-w64-mingw32-as: nix-store-tests.exe.p/meson-generated_nix-store-tests-unity0.cpp.obj: too many sections (32814)
.../cchryRsB.s: Fatal error: can't write 16 bytes to section .text of nix-store-tests.exe.p/meson-generated_nix-store-tests-unity0.cpp.obj: 'file too big'
ninja: build stopped: subcommand failed.

Reproduced on master 3aef07e8f, and identically on an unrelated branch, so it is not
branch-specific.

Why

The meson summary for that build reports:

unity       : on
unity_size  : 8192

so every source file in src/libstore-tests lands in one unity0.cpp. In C++ each template
instantiation and inline function gets its own COMDAT section, so one object covering the whole
suite reaches 32814 sections, and as refuses. The object-file name in the error
(meson-generated_nix-store-tests-unity0.cpp.obj) is the unity TU rather than any individual source,
which is what points at the unity build rather than at any one file.

nix-store-tests appears to be the only suite large enough to hit this. In the same configuration
nix-util-tests, nix-expr-tests, nix-fetchers-tests and nix-flake-tests all cross-compile
without complaint.

Consequence

This is not only a build annoyance. It means nix-store-tests can never be part of Windows CI
regardless of what else is fixed, because the artifact does not exist. That is one of the five
suites in #16360, and it is the one that fails for a reason unrelated to the other four.

Possible fixes

Either disable unity for this target when cross-compiling to mingw, or lower unity_size so meson
emits several smaller unity TUs instead of one. The second keeps most of the unity build's benefit
and is the smaller change, but I have not measured how low it needs to go, and I would rather not
guess at a number that happens to work today and breaks again as the suite grows. Turning unity off
for this one target on this one platform is the option that cannot silently regress.

Found while measuring which of the five cross-built suites can run under Wine, in connection with
#16360, #16363 and #16364.

[awsmadi]

Verified the fix rather than leaving it as a suggestion. Replacing the unity flags (not appending,
which meson rejects with Got argument unity as both -Dunity and --unity. Pick one.) builds cleanly:

p.overrideAttrs (o: {
  mesonFlags =
    (builtins.filter (x: x != "-Dunity=on" && x != "-Dunity_size=8192") o.mesonFlags)
    ++ [ "-Dunity=off" ];
})

/nix/store/541vi2fdh75dw2mbqxz88dzzzr4ckzqk-nix-store-tests-x86_64-w64-mingw32-2.36.0pre

So the section-count overflow is entirely the unity build, and -Dunity=off for this target is
sufficient. No source change is needed.

Worth knowing what is behind it: the resulting nix-store-tests.exe then dies under Wine at exit 5
with no output at all, which is #16363 — it links libstore, so it hits the static-initialisation
throw that #16364 fixes. Fixing this issue does not by itself get the suite running, it gets it to
the same starting line as nix-expr-tests, nix-fetchers-tests and nix-flake-tests.

[xokdvium]

Bad bot. Instead of nuking unity we can unconditionally enable large objects for all targets.

[awsmadi]

You're right, and it works. Keeping unity on and adding -Wa,-mbig-obj:

/nix/store/ky8l6az5nvq60jq6253hpynbgqn1n6jj-nix-store-tests-x86_64-w64-mingw32-2.36.0pre

Same source, same -Dunity=on -Dunity_size=8192, builds clean. Better than what I suggested on two
counts: the unity build's benefit is kept, and it removes the objection I raised against my own
proposal, namely that lowering unity_size means picking a number that works today and breaks again
as the suite grows. Enabling the extended COFF format has no such ceiling to creep up on.

One incidental note in case it saves someone a minute: -mbig-obj does not appear in
x86_64-w64-mingw32-as --help on binutils 2.46, so grepping the help text suggests it is unsupported.
It is supported.

I'll leave the issue title and the "possible fixes" section as they are rather than quietly rewrite
history under your comment — say the word and I'll edit the body to lead with big-obj, or close this
in favour of a PR if you'd rather just land it.

Separately, and this is the part I care about: once it builds, nix-store-tests.exe still cannot run
on master, because it links libstore and dies during static initialisation before main — even
--gtest_list_tests exits 5 with no output. So this issue plus #16363 are both required before that
suite reports anything. I'm measuring now whether it passes with both applied and will follow up with
the numbers either way.

[awsmadi]

Opened #16367 implementing your suggestion.

It turned out not to need a new flag at all: nix-meson-build-support/big-objs already exists and
already does -Wa,-mbig-obj on Windows, and its comment describes this exact failure. It was just
only included by src/libexpr, added for primops.cc. So the change is to include it wherever
windows-version already is — one line in each of 22 meson.build files, and a no-op off Windows.

Verified from that branch with no overrides: nix-store-tests-x86_64-w64-mingw32 builds,
nix-util-tests and nix-cli cross still build, and the native nix-store-tests still builds, which
is the check that matters given it touches 22 files.

Happy for you to close this issue in favour of the PR, or to take it over — I have not edited the
issue body, so the original "disable unity" suggestion is still there above your correction rather than
quietly rewritten.