stdenv/cygwin: add cross bootstrap tools

[corngood]

I've built a working stdenv based on this, but I think this is a good starting point to get it merged.

Once this is in we should be able to get a tarball from hydra.

I'm marking this draft until I enumerate the package changes required for it to build.

Build with:

nix build -f pkgs/top-level/release-cross.nix bootstrapTools.x86_64-pc-cygwin.unpack

Dependencies:

• cc-wrapper: cc-wrapper: set gl_cv_clean_version_stddef=yes on cygwin #468206
• {cc,bintools}-wrapper: {cc,bintools}-wrapper: use executable extension when set #479741
• libxcrypt: libxcrypt: fix cygwin build #476257
• file: file: fix cross build for windows platforms #476283
• gnumake: gnumake: fix build on cygwin #476284
• gzip: gzip: fix cygwin build #476285
• zlib-ng: zlib-ng: fix cygwin build #476286
• gettext: gettext: fix cygwin build #476288
• gnutar: gnutar: fix cygwin build #476289
• mpfr: mpfr: fix cygwin build #476290
• gmp: gmp: fix cygwin build #476291
• isl: isl: fix cygwin build #476292
• coreutils: coreutils: fix cygwin build #476294
• git: git: fix cygwin build #476295
• deterministic-uname: deterministic-uname: add cygwin support #476296
• binutils: binutils: fix cygwin build #476298
• cygwin-dll-link: cygwin-dll-link: improvements from testing on native cygwin #476301
• gcc: gcc: fix cygwin build #476299
• gettext: gettext: remove obsolete cygwin patches #493522
• zlib: zlib: fix cygwin build #493530

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[corngood]

Ideally, this would use something similar to the linux minimal-bootstrap path to bootstrap fully from source without using the bootstrap-files mechanism, for reproducibility and auditability reasons. Is there any way to do that with Cygwin?

I'm sure it's possible, but I think it's premature when the only stdenv currently doing it is x86 linux. I suspect we'd want to refactor and share a lot of linux/minimal-bootstrap. I don't think cygwin is the platform we want to use to build that abstraction. Darwin or freebsd would probably be better.

[pyrox0]

Ideally, this would use something similar to the linux minimal-bootstrap path to bootstrap fully from source without using the bootstrap-files mechanism, for reproducibility and auditability reasons. Is there any way to do that with Cygwin?

I'm sure it's possible, but I think it's premature when the only stdenv currently doing it is x86 linux. I suspect we'd want to refactor and share a lot of linux/minimal-bootstrap. I don't think cygwin is the platform we want to use to build that abstraction. Darwin or freebsd would probably be better.

Very fair, then feel free to discard my comments. The work here looks good!

[corngood]

I've marked this ready because all the original dependencies are merged, and I think the change is still good.

Unfortunately it doesn't build at the moment due to regressions, which I'll fix and link in the top comment.

[Ericson2314]

Can we just cross compile from a pure bootstrap platform and say, well, you need multiple types of builders if it isn't cached?

I don't see why not.

[corngood]

Can we just cross compile from a pure bootstrap platform and say, well, you need multiple types of builders if it isn't cached?

I did have a stdenv based on stdenv/cross before this one. It would be very frustrating for an end user IMO.

This is quite similar to what freebsd and darwin do. This change doesn't even have the stdenv yet. I really just want all the things required by stdenv to be in hydra, so we can keep them building while we do the rest of the work.

I think long-term, minimal-bootstrap would be a great way to go, but it's very linux-centric at the moment.

[Ericson2314]

#123095 (comment) to be clear, something like this is what I am thinking.

We can make a "make bootstrap tools" of sorts, but rather than using it to produce something we fetch in a separate eval, we would just directly use it in the native bootstrap. We'd rely on regular substitution rather than fetching a fixed output.

[corngood]

#123095 (comment) to be clear, something like this is what I am thinking.

Like with minimal-bootstrap, I'm not against this idea, but I'd rather start off with a conventional stdenv (like darwin/freebsd) until the concept has been proven.

[Ericson2314]

I don't want to block @corngood, and he made some good points about exotic platforms have enough "innovation budget already", but I do think this should be reworked as soon as the time comes to upload bootstrap binary binaries to nixos.org -- at that point, we're better just depending on the cross-compiled bootstrap tools directly.